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ABSTRACT 


A  2010  review  of  96  defense  acquisition  programs  showed  average  delivery  rates  are  22 
months  behind  schedule  and  the  cumulative  cost  growth  exceeded  $296  billion.  With 
budget  cuts  looming,  a  small  window  of  opportunity  exists  to  enact  reforms  improving 
the  health  and  solvency  of  the  defense  acquisition  portfolio.  First,  we  must  leverage  the 
technology  investments  made  into  collaborative  software  suites  such  as  product  lifecycle 
management  (PLM)  to  align  the  requirements,  design,  engineering,  logistics, 
maintenance,  and  operational  data  environments  into  one  comprehensive  activity. 
Implementing  a  PLM  strategy  will  present  cost-saving  opportunities  through  faster 
information  access,  improved  data  reuse,  social  networking,  and  virtual  collaboration  and 
testing.  PLM  systems  have  the  ability  to  capture  and  organize  vast  amounts  of  data. 
Because  through  human  interaction  data  becomes  knowledge,  lean  product  design  is  a 
philosophy  that  can  change  how  we  think,  learn,  use,  and  build  up  on  that  knowledge.  By 
going  beyond  merely  attacking  waste  by  finding  a  balance  between  waste  reduction  and 
value  addition,  total  ownership  costs  can  be  reduced  drastically.  These  reforms  have  the 
ability  to  fundamentally  change  how  we  design,  build,  and  maintain  the  fleet,  making  the 
defense  portfolio  solvent  and  thus  continuing  to  fulfill  the  needs  of  the  warfighter. 
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I.  INTRODUCTION 


A.  BACKGROUND 

The  United  States  has  a  broad  set  of  national  security  missions  that  it  must  be 
prepared  to  complete.  To  accomplish  these  missions,  an  equally  broad  set  of  weapon 
systems  must  be  developed  by  the  acquisition  community,  providing  capabilities  to  our 
warfighters  and  ensuring  they  hold  the  advantage  regardless  of  the  mission  or  task.  To 
accomplish  its  assigned  missions,  the  United  States  Navy  builds  and  operates  the  most 
sophisticated,  technologically  advanced  ships  in  the  world.  Since  2002,  Congress  has 
appropriated  over  $74.1  billion  for  the  construction  of  new  aircraft  carriers,  nuclear 
submarines,  surface  combatants,  and  amphibious  transport  ships  (Government 
Accountability  Office  [GAO],  2009b). 

Any  inefficiency  through  the  acquisition  process  will  consume  resources,  leaving 
fewer  available  to  invest  in  the  weapon  systems  of  tomorrow.  One  indicator  that 
inefficiencies  are  present  in  the  current  process  is  the  unexpected  cost  growth  and 
schedule  delays  of  recent  programs.  A  2010  Government  Accountability  Office  (GAO) 
report  (Table  1)  reviewed  the  perfonnance  of  96  major  defense  acquisition  programs  in 
2009  and  showed  that  average  delivery  rates  are  22  months  behind  schedule  and  running 
at  a  cumulative  cost  growth  of  $296  billion  (GAO,  2010). 
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Table  1.  Analysis  of  the  DoD  Acquisition  Portfolio 

(From  GAO,  2010) 


Fiscal  year  2009  dollars 

Fiscal  year 

2003 

2007 

2008 

Portfolio  size 

Number  ol  programs 

77 

95 

96 

Total  planned  commitments 

si-2  tnilion 

Si  .6  billion 

SI  .6  thilion 

Commitments  outstanding 

S724.2  billion 

S875.2  billion 

$786.3  billion 

Portfolio  Indicators 

Change  to  total  RDT&F  costs  from  first 
estimate 

37  percent 

40  percent 

42  percent 

Change  to  total  acquisition  cost  trom 
first  estimate 

19  percent 

26  percent 

25  percent 

Total  acquisition  cost  growth 

SI  83  billion 

S301.3  billion1 

$296.4  billion 

Share  ol  programs  with  25  percent 
Increase  In  program  acquisition  unit 
cost  growth 

41  percent 

44  percent 

42  percent 

Average  schedule  delay  in  delivering 
initial  capabilities 

18  months 

21  months 

22  months 

The  Honorable  Gene  Taylor,  congressional  representative  from  Mississippi, 
speaking  on  the  state  of  the  acquisition  portfolio,  said  “Our  ships  are  simply  too 
expensive.  [...]  I  believe  the  Navy  needs  to  look  very  hard  at  their  requirements  process  to 
determine  if  marginal  extra  capability  is  worth  significant  construction  or  integration 
costs”  ( Opening  Statement,  2009). 

Congressman  Taylor  was  speaking  to  the  fact  that  through  fiscal  year  (FY)09,  the 
Navy  has  seen  cost  growth  across  every  major  current  program,  the  worst  being  Littoral 
Combat  Ship,  which  saw  an  increase  of  208%  from  the  original  estimate,  as  shown  in 
Table  2  (Department  of  Defense  [DoD],  2010).  Because  of  these  high  costs,  Congress  or 
the  Navy  could  decide  to  kill  the  troubled  program,  or  pay  the  additional  cost  growth 
either  by  placing  an  additional  burden  on  the  tax  payers  or  by  cutting  the  funds  from 
other  programs.  Both  of  these  actions  would  result  in  fewer  capabilities  for  warfighters. 
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Table  2.  Program  Budget  Cost  Growth  for  Ships  Under  Construction  in  2009 

(After  DoD,  2010) 


Program  Acquisition  Cost  Summary  (Dollars  ir 

Millions) 

As  of  December  31,  2009 

Program 

|  Baseline  Estimate  j 

|  Current  Estimate  j 

%  Change  to  date 

|  Then  Year  $  | 

Quantity 

1  $/hull  | 

|  Then  Year  $  | 

Quantity 

$/hull  I 

Then  Year  $ 

CVN  78 

$ 

36,082 

3 

$ 

12,027 

$ 

40,546 

3 

$ 

13,515 

12.4% 

DDG  1000 

$ 

36,296 

10 

$ 

3,630 

$ 

19,771 

3 

$ 

6,590 

17.4% 

DDG51 

i  - 

$ 

20,118 

23 

s 

875 

$ 

80,408 

71 

$ 

1,133 

21.4% 

LCS 

s 

1,212 

2 

s 

606 

$ 

3,733 

2 

$ 

1,866 

208.0% 

LPD  17 

s 

10,762 

12 

s 

897 

$ 

18,659 

11 

$ 

1,696 

101.0% 

SSN  774 

$ 

71,081 

30 

$ 

2,369 

$ 

91,394 

30 

$ 

3,046 

28.6% 

T-AKE 

$ 

4,890 

12 

$ 

408 

$ 

6,889 

14 

$ 

492 

16.9% 

The  expensive  nature  of  ships  referred  to  by  Congressman  Taylor  is  not  limited  to 
the  acquisition  costs.  Total  Ownership  Cost  (TOC)  includes  all  costs  associated  with  the 
research,  development,  procurement,  operation,  and  disposal  of  an  individual  weapon 
system  over  its  full  life.  Commenting  on  the  high  cost  of  weapon  systems,  General 
Joseph  W.  Ralston,  former  commander  of  Air  Combat  Command,  has  observed  that  “The 
B-l  bomber  cost  of  ownership  is  more  threatening  to  the  aircraft  than  the  enemy”  (Reed, 
2003). 

Traditionally,  the  cost  to  procure  a  system  (as  shown  in  Figure  1)  is 
approximately  28%  of  the  total  ownership  cost,  with  the  remainder  representing  the  cost 
to  operate  and  maintain  the  product  through  its  lifecycle  and  eventual  disposal  (General 
Accounting  Office  [GAO],  2003b). 


Figure  1.  Typical  DoD  Program  Life  Cycle  Cost,  30-Year  Service  Life 

(From  GAO,  2003b) 


3 


While  a  majority  of  the  TOC  will  occur  during  the  operations-and-support  phase 
of  a  program,  Figure  2  demonstrates  how  decisions  made  while  crafting  requirements  and 
maturing  the  design  will  dictate  operating  and  support  expenditures.  This  is  similar  to 
purchases  made  with  a  credit  card — you  can  buy  anything  today,  but  at  the  end  of  the 
month,  the  bill  will  be  waiting.  Making  poor  decisions  early  can  leave  a  program  with 
bills  that  cannot  be  paid.  Failing  to  consider  TOC  in  the  acquisition  strategy  is  like 
making  an  impulse  purchase  without  considering  the  real  cost.  The  GAO  cites  studies 
demonstrating  that  by  the  time  10%  of  lifecycle  costs  have  been  spent,  about  85%  of 
operating  and  support  costs  have  been  detennined  by  set  requirements.  By  the  time  the 
product  is  ready  for  production,  90%  of  TOC  is  locked  in,  while  only  28%  has  been 
expended  (GAO,  2003b).  Understanding  the  ramifications  early  decisions  have  on  the 
TOC  will  help  to  ensure  that  decisions  made  are  the  best  in  regard  to  the  entire  lifecycle. 


Figure  2.  Operating  and  Support  Costs  through  the  Acquisition  Process 

(From  GAO,  2003b) 

In  a  2003  study  on  ways  to  reduce  the  TOC,  the  GAO  identified  three  primary 
reasons  that  weapon  systems  have  experienced  costly  maintenance  problems  and  low 
readiness  rates.  First,  during  the  early  stage  design,  when  decisions  have  the  greatest 
effect,  the  Department  of  Defense  (DoD)  overemphasizes  technical  perfonnance 
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capabilities  at  the  expense  of  operating,  support,  and  readiness.  Second,  the  reliance  on 
immature  technologies  to  meet  performance  goals  decreases  the  ability  to  design  weapon 
systems  with  high  reliability.  As  the  technology  matures,  the  design  evolves  to 
accommodate  differences  from  the  original  estimate,  sometimes  the  requirements  of  the 
technology  are  not  fully  understood  until  after  construction  has  begun.  Immature 
technologies  limit  the  ability  to  plan  for  inclusion  of  various  cost-saving  manufacturing 
techniques,  such  as  open  systems  or  parts  reduction.  Third,  the  current  organizational 
structure  limits  collaboration  and  feedback  between  departments,  creating  stovepipes 
responsible  for  requirements  generation,  product  development,  and  maintenance.  The 
current  system  the  DoD  uses  to  capture  and  analyze  currently  fielded  systems-operation 
and  maintenance  data  is  unreliable,  making  it  difficult  to  understand  the  total  cost  of 
operations  and  support.  These  stovepipes  prohibit  the  proper  exchange  of  information, 
resulting  in  inefficient  behavior  such  as  ship  alterations  scheduled  immediately  upon 
delivery,  versus  working  with  the  builder  to  make  the  corrections  or  improvements  while 
in  production  (GAO,  2003b).  By  enacting  reforms  addressing  root  causes  behind  the  cost 
escalation  and  schedule  delays  during  procurement  and  making  conscious  decisions  that 
positively  influence  TOC,  the  Navy  can  make  more  efficient  use  of  the  appropriated 
budget.  However,  being  good  stewards  of  taxpayer  dollars  is  not  the  only  reason  to 
consider  changing  how  the  Naval  acquisition  community  operates. 

The  U.S.  government  is  projected  to  spend  $3.5  trillion  in  FY10 — approximately 
20%  of  gross  domestic  product  (GDP).  Of  that  amount,  38%  ($1.37  trillion)  is 
considered  “discretionary”  spending  and  funds  the  12  major  federal  government  agencies 
and  departments.  The  largest  of  those  is  the  Department  of  Defense  (DoD),  which 
consumes  nearly  half  of  the  discretionary  budget,  or  $663  billion  (Office  of  Management 
and  Budget  [OMB],  n.d.). 

The  DoD  is  a  major  target  for  spending  reductions  because  it  is  8.5  times  larger 
than  the  next  largest  department.  Figure  3  shows  that  based  on  historic  trends,  cuts  in 
defense  spending  should  be  expected.  Connie  Bowling,  a  senior  TOC  advisor  for  Naval 
Sea  Systems  Command  (NAVSEA)  and  Navy  headquarters,  points  out  that  after  a  major 


5 


war  period,  defense  spending  has  contracted  by  30%  and  then  risen  by  30%  over  the 
course  of  the  next  war  (McPherson  &  Bowling,  2009). 

Figure  3  shows  that  we  may  already  be  past  the  peak  of  this  spending  cycle.  This 
conclusion  coincides  with  Secretary  of  Defense  Robert  Gates’s  comments  during  a 
speech  at  Eisenhower  Library  in  Kansas,  during  which  he  said,  “Given  America’s 
difficult  economic  circumstances  and  perilous  fiscal  condition,  military  spending  on 
things  large  and  small  can  and  should  expect  closer,  harsher  scrutiny.  [  ...]  The  gusher 
has  been  turned  off,  and  will  stay  off  for  a  good  period  of  time”  (Dreazen,  2010).  As 
public  opinion  continues  to  exert  tremendous  pressure  on  the  government  to  become 
more  accountable  for  its  spending,  the  probability  increases  that  the  defense  budget  will 
be  cut.  The  DoD  should  prepare  for  these  cuts  by  ensuring  that  best  practices  are 
implemented  now,  to  maximize  the  value  delivered  to  the  warfighters  and  avoid  the  need 
for  hasty  decisions  as  budgets  are  cut. 
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When  the  hostilities  in  Iraq  and  Afghanistan  finally  end,  it  is  highly  probable  that 
cuts  to  the  defense  budget  will  shortly  follow  to  compensate  for  other  areas  of  national 
interest  that  have  been  financially  neglected.  These  hostilities  have  put  an  incredible 
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stress  on  the  military’s  equipment — not  only  has  the  operational  environment  been  brutal, 
but  in  order  to  keep  systems  operationally  available,  regular  maintenance  has  been 
deferred  or  ignored.  For  example,  helicopters  are  flying  two  or  three  times  their  planned 
usage  rates.  Tank  crews  are  driving  more  than  4,000  miles  a  year,  five  times  the  normal 
rate.  Truck  fleets  that  convoy  supplies  down  Iraq’s  bomb-laden  roads  are  running  at  six 
times  the  planned  mileage  (Tyson,  2006). 

An  estimated  $17  billion-plus  worth  of  military  equipment  is  destroyed  or  worn 
out  each  year,  blasted  by  bombs,  ground  down  by  desert  sand,  or  used  up  to  nine  times 
the  rate  of  expenditure  compared  to  times  of  peace  (Hochberg,  2007).  This  equipment 
must  be  repaired  or  replaced.  At  the  same  time,  funds  are  needed  to  build  the  systems  of 
tomorrow  that  will  be  ready  to  replace  the  old  or  wom-down  systems. 

To  accomplish  all  of  these  goals,  the  acquisition  process  must  be  very  efficient 
with  the  funds  appropriated,  to  develop  systems  utilizing  best  practices  that  strive  to  find 
a  balance  between  maximizing  capabilities  for  the  warfighter  and  minimizing  the  TOC, 
which  causes  a  strain  on  budgets. 

In  order  to  address  the  root  causes  behind  the  cost  volatility  and  schedule  delays, 
as  well  as  make  prudent  TOC  decisions  based  on  the  entire  lifecycle,  the  Navy  needs  to 
take  action.  Investment  in  the  right  technologies  can  provide  the  workforce  capability 
and  features  that  can  lead  to  an  improved  knowledge  base.  Improved  knowledge  can  lead 
to  informed  decision  making  and  to  building  an  organizational  history  that  ensures 
lessons  are  learned  from  mistakes  instead  of  repeated,  which  leads  to  refonning  the 
practices,  processes,  and  organizations  and  to  making  better  use  of  the  available 
resources. 
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B.  RESEARCH  QUESTIONS 

What  is  needed  is  a  balance  between  the  design  selected  to  meet  the  warfighters’ 
needs  and  the  resources  (funding,  technology,  design  knowledge,  engineering  capacity, 
etc.)  available  to  transform  the  idea  into  a  functioning  product.  The  following  research 
questions  established  the  framework  and  served  as  an  underlying  guide  throughout  this 
research: 

1 .  How  can  a  technology  such  as  collaborative  product  lifecycle  management  (PLM) 
be  used  to  improve  the  acquisition  process? 

2.  What  reforms  to  the  acquisition  process  are  possible,  complimenting,  or 
supplementing  the  capabilities  provided  by  collaborative  PLM,  helping  ensure 
value  is  optimized  throughout  the  lifecycle  of  the  product? 


8 


II.  SCOPE  AND  METHODOLOGY 


A.  RESEARCH  METHODOLOGY 

The  research  methodology  used  is  non-numerical  and  descriptive  and  will  apply 
reasoned  arguments  supported  by  external  sources.  This  is  an  applied,  qualitative 
research  methodological  approach.  The  goal  of  this  study  is  to  find  a  solution  to  improve 
the  perfonnance  of  our  acquisition  programs.  Staying  inside  the  applied  research 
approach,  the  solutions  were  crafted  from  well-supported  and  accepted  theories  and 
principles.  The  research  is  categorized  as  qualitative  because  the  focus  is  on  experience, 
aimed  to  acquire  the  implications  and  opinions  describing  the  situation,  as  opposed  to 
numerically  prove  or  disprove  a  hypothesis  through  experimentation. 

Due  to  the  immensity  and  complexity  of  ship  lifecycle,  systems  analysis  based 
studies  should  be  conducted  to  examine  and  evaluate  a  variety  of  issues  such  as 
requirements  development,  technology  maturity,  construction,  operation,  and 
sustainment.  This  thesis  demonstrates  how  the  collaborative  PLM  tool  suite  can 
supplement  other  reforms  of  the  acquisition  process  to  deliver  a  product  that  meets 
requirements  while  improving  the  return  on  investment. 

B.  RESEARCH  OBJECTIVE  AND  SCOPE 

The  research  objectives  are  twofold.  The  first  is  to  find  companies  that  have  had 
success  addressing  similar  issues  plaguing  DoD  acquisitions  and  to  determine  whether 
these  commercial  best  practices  offer  opportunities  to  improve  the  outcomes  in  DoD 
acquisitions  and  aid  its  efforts  to  improve  the  value-to-cost  ratio  of  its  fleet.  The  second  is 
to  determine  if  a  PLM  approach  could  facilitate  these  practices. 

One  of  the  best  opportunities  to  reduce  the  risk  associated  with  an  acquisition 

program  is  early  in  the  design  phase  where  the  program  has  the  greatest  flexibility  and  a 

course  correction  results  in  minimal  disruption  and  the  need  for  rework.  This  thesis  does 

not  exclude  any  phase  of  an  acquisition  program,  but  focuses  primarily  on  reforms 

applicable  to  the  time  early  in  the  design  phase.  The  belief  is  that  a  solid  design  is  the 

foundation  of  a  successful  program.  A  helpful  attribute  of  a  solid  foundation  is  the 
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integration  of  each  phase  of  a  product  lifecycle,  in  order  to  capture  experience  and 
knowledge  unique  to  that  phase,  and  then  use  this  knowledge  to  influence  positive 
decisions  during  design.  This  research  will  also  show  ways  this  knowledge  can  assist  the 
design  team  in  optimizing  value  to  the  stakeholders  across  all  phases. 

C.  RESEARCH  DATA  SAMPLE 

A  multitude  of  literature,  including  government  white  papers,  industry  point 
papers,  GAO  reports,  program  lessons  learned,  books,  and  journal  articles  concerning 
best  practices  and  lessons  learned  during  the  product  development  phase  were  studied  for 
this  thesis.  The  opinions  formed  were  based  on  which  processes  offered  the  greatest 
return  on  investment  and  how  current  technologies  can  act  as  a  facilitator  for 
implementation  of  the  identified  processes. 

The  author  was  granted  access  and  was  provided  with  internal  documents  such  as 
lessons  learned  and  whitepapers,  as  well  as  met  or  spoke  with  representatives  from 
current  Navy  programs  such  as  LPD  17,  DDG  1000,  LCS,  SSN  774,  and  CVN  78. 
Observation  of  active  programs’  daily  operations  provided  insight  on  issues  experienced, 
reasoning  behind  decisions  made,  and  lessons  learned  from  mistakes,  among  other 
general  observations.  These  programs  were  selected  because  they  are  current  and  offered 
the  best  perspective  of  the  state  of  the  acquisition  process. 

The  United  Airlines  engine  maintenance  facility  in  San  Francisco  also  provided 
data  and  access  that  aided  my  research.  They  offered  meetings  with  engineers  and  tours 
of  the  facility,  to  see  how  United  closed  the  information  loop  throughout  the  engine 
lifecycle.  Other  private-sector  companies  provided  information,  white  papers,  interviews, 
and  case  studies;  however,  due  to  proprietary  information,  my  access  was  limited. 

The  capabilities  of  collaborative  PLM  and  the  evolution  of  LEAN  product 
development  (LPD)  was  learned  from  literature  provided  and  interviews  conducted  with 
professionals,  including  the  founder  of  Huthwaite  Innovation  Institute  and  experts  from 
Siemens  Product  Lifecycle  Management  Software,  Dassault  Systems  Solutions,  John 
Stark  Associates,  SofTech,  Ship  Constructor  Shipbuilding  Software,  and  the  Center  for 
Naval  Shipbuilding  Technology.  This  helped  to  develop  an  understanding  of  how  LPD 
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philosophy  was  built  into  and  supported  by  collaborative  PLM  tools.  These  experts 
helped  me  understand  the  best  practices  and  lessons  they  had  learned  from  commercial 
programs,  which  have  successfully  integrated  collaborative  PLM  tools  into  their 
processes,  and  most  importantly,  how  these  practices  can  be  applied  to  naval  acquisition 
programs. 

1.  Data  Collection  Process 

To  compensate  for  lack  of  personal  experimentation,  my  research  leveraged 
experiments  and  projects  conducted  by  both  the  government  and  the  private  industry  to 
address  the  issues  discussed  in  the  paper.  The  GAO  has  created  extensive  case  studies 
examining  commercial  best  practices,  and  it  has  explored  weaknesses  in  the  DoD 
acquisition  framework.  These  reports  reinforced  lessons  learned  from  the  programs  and 
companies  that  made  data  available,  and  they  introduced  new  concepts  and  ideas. 
Several  of  these  studies  were  utilized  to  determine  how  the  best  practices  identified  by 
GAO  could  apply  to  DoD  acquisitions  and  be  facilitated  by  the  collaborative  PLM 
approach. 

2.  Data  Analysis 

The  author  obtained  an  understanding  of  the  government  shipbuilding  processes, 
insight  into  recent  lead-ship  programs  and  specific  commercial  practices  while 
conducting  a  series  of  interviews  with  government  subject-matter  experts  from 
NAVSEA,  the  Center  for  Innovation  in  Ship  Design,  Ship  System  Integration  and  Design 
Department,  former  NAVSEA  chief  architects,  current  Naval  architects,  Supervisors  of 
Shipbuilding,  program  managers,  and  Program  Executive  Office  Ships  representatives. 

In  particular,  the  ASNE  Day  2010  conference  titled  Engineering  the  Affordable 
Global  Navy  through  Innovation  offered  a  tremendous  opportunity  for  me  to  listen  to 
panels  of  experts  representing  both  the  government  and  private  industry  discussing  the 
impact  of  not  controlling  ship  TOC,  as  well  as  their  thoughts  on  initiatives  that  could 
address  current  issues.  This  conference  afforded  me  the  ability  to  broaden  my 
perspective  by  meeting  with  representatives  from  commercial  shipyards  responsible  for 

developing  complex  ship  solutions:  Northrop  Grumman,  Austal,  and  General  Dynamics. 
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Meeting  with  individuals  from  these  companies  provided  the  opportunity  to  hear  their 
opinions  on  current  efforts  as  well  potential  solutions  that  have  yet  to  be  attempted.  The 
author  was  also  able  to  present  his  own  opinions,  which  led  to  a  discussion  of  the 
strengths  and  weaknesses  of  the  proposals,  leading  to  a  more  realistic  product.  One  of 
the  most  thought  provoking  events  during  this  conference  was  the  Global  Shipbuilding 
Executive  Summit,  where  global  leaders  representing  both  the  private  and  public  sectors 
held  a  brainstonning  session  on  potential  solutions  to  address  the  unsustainable  trend  of 
poor  cost,  schedule,  and  technical  performance  across  the  defense  portfolio.  This  data 
established  a  foundation  of  understanding  necessary  to  complete  this  research. 
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III.  PRODUCT  LIFECYCLE  MANAGEMENT 


A.  BACKGROUND 

This  section  provides  an  introduction  to  a  technology  that  can  assist  with 
implementing  the  new  possible  strategy,  collaborative  PLM,  a  promising  tool  that,  as  its 
name  implies,  allows  for  the  management  of  the  product  from  the  earliest  stages  of  the 
lifecycle,  all  the  way  through  to  disposal. 

Follow-on  chapters  will  present  practices  and  processes  that  can  help  reform  the 
naval  acquisition  community.  The  recommended  reforms  either  take  advantage  of  the 
capabilities,  or  they  are  needed  to  support  the  deployment  of  a  collaborative  PLM  across 
the  naval  acquisition  enterprise.  The  reforms  are  based  on  lessons  learned  and  best 
practices  from  companies  that  have  successfully  institutionalized  collaborative  PLM  into 
their  organizations.  None  of  these  reforms  are  groundbreaking;  in  fact,  the  proven 
practices  and  process  have  been  successfully  implemented  by  several  DoD  programs. 
However,  on  a  whole,  our  corporate  knowledge  never  seems  to  improve  as  the  successes 
or  lessons  learned  from  the  failures  are  isolated  and  not  effectively  communicated  across 
the  portfolio.  It  is  not  only  necessary  to  improve  the  practices  and  processes,  thus, 
improving  the  organizational  productivity,  but  also  a  new  strategy  is  necessary  to  learn 
and  retain  corporate  knowledge,  to  prevent  taking  any  steps  backwards  in  order  to  move 
forward. 

The  Navy  is  constantly  looking  for  initiatives  to  address  weaknesses  or  correct 
deficiencies  that  lead  to  problems  such  as  cost  overruns  and  schedule  delays,  among 
others.  However,  whether  due  to  size,  authority,  or  some  other  reason,  most  of  these 
initiatives  have  been  limited  to  one  functional  area  or  even  a  subdivision  of  one 
functional  area,  such  as  design,  engineering,  manufacturing,  sales,  or  service.  For 
instance,  LEAN  manufacturing  has  eliminated  a  lot  of  waste  from  the  manufacturing 
realm,  but  generally  does  not  attempt  to  address  the  waste  encountered  throughout  the 
entire  lifecycle. 
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However,  optimizing  performance  in  one  or  even  a  series  of  functional  areas  does 
not  necessarily  result  in  the  optimization  of  the  entire  organization.  The  problem  is  that 
different  departments  of  organizations  have  become  silos  of  information.  Collaborative 
PLM  links  the  different  functional  areas  through  shared  product  information,  breaks 
down  the  silos,  and  gains  benefits  from  a  shared  base  of  information.  For  instance, 
imagine  a  car  designed  to  take  advantage  of  the  most  efficient  sequence  of  construction. 
The  car  company  could  take  the  savings  from  construction  to  undercut  the  competition 
and  expect  this  new  car  to  be  very  successful.  However,  if  this  new  design  overlooked 
that  the  only  way  to  change  oil  was  to  remove  the  entire  engine  block,  requiring  an 
expensive  overhaul  of  the  car  every  3,000  miles,  it  would  not  be  very  appealing  to  car 
buyers.  The  designers  could  misdiagnose  the  reason  behind  the  poor  sales  figures  and 
add  additional  cup  holders  to  attempt  to  increase  the  appeal.  A  mechanic  knows  the  real 
reason  that  the  car  is  unpopular,  but  if  that  knowledge  is  never  communicated  and 
captured,  this  new  design,  which  might  overall  be  a  tremendous  improvement,  will  be 
abandoned  as  a  failed  design.  Collaborative  PLM  enables  an  organization  to  completely 
integrate  and  then  leverage  everything  related  to  the  product,  in  an  attempt  to  maximize 
productivity.  Collaborative  PLM  uses  information  technology  and  organizational 
practices  and  processes  to  improve  efficiencies  both  within  and,  more  importantly,  across 
the  traditional  functional  divisions. 

A  common  theme  during  the  ASNE  Day  2010  conference  titled  “Engineering  the 
Affordable  Global  Navy  through  Innovation”  was  the  voicing  of  concern  over  the  cost 
escalation  across  the  Navy  acquisition  portfolio.  Adding  to  this  concern  was  the  lack  of 
results  achieved  by  various  cost-reduction  strategies.  An  advantage  of  collaborative  PLM 
is  that  it  does  not  address  a  problem  from  solely  a  cost-reduction  perspective.  As  with  the 
car  design  example,  collaborative  PLM  offers  the  ability  to  facilitate  increased 
innovation,  functionality,  and  quality,  by  organizing  the  intellectual  capital  of  an 
organization.  As  the  old  adage  goes,  “you  can’t  simply  save  your  way  to  prosperity” 
(Grieves,  2006).  Building  better,  more  creative,  and  more  useful  products  with  the  same 
or  fewer  resources  can  drive  productivity;  it  is  a  better  business  model  than  simply 
cutting  costs. 
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B.  COLLABORATIVE  PLM  DEFINED 

The  origins  of  collaborative  PLM  lie  in  the  computer-aided  design  (CAD)  market 
and  how  it  initially  generated  designs — first  2D  and  now  3D.  As  technology  progressed, 
the  CAD  programs  started  incorporating  more  knowledge  capabilities  into  their  drawings 
(e.g.,  material  characteristics,  notes,  part  numbers).  This  change  accompanied  programs 
that  linked  other  data,  not  associated  directly  with  the  CAD  file  (engineering  data 
management  (EDM)  and  product  data  management  (PDM)).  Computer-integrated 
manufacturing  (CIM)  was  created,  which  could  use  the  CAD  models  for  computerized 
machining,  simulation,  or  testing.  While  all  these  steps  were  useful  and  had  similar 
goals,  not  being  integrated  meant  they  were  islands  of  automation,  creating  bottlenecks  or 
errors,  as  information  had  to  be  manually  transferred  from  one  tool  to  the  next,  if  it  was 
transferred  at  all.  This  meant  that  even  if  individual  activities  or  tasks  were  efficient,  the 
overall  practices  and  processes  used  and  products  created  still  had  room  to  improve.  The 
success  of  an  organization  centers  on  the  ability  to  remain  in  control  versus  being 
controlled  by  its  products.  In  other  words,  think  of  the  difference  between  laying  out  a 
plan  and  executing  it,  making  calculated  decisions  and  understanding  the  ramifications, 
versus  constantly  moving  from  one  emergency  to  the  next,  trying  to  put  out  fires,  making 
snap  decisions  without  thinking  the  problem  through.  Loss  of  control  during 
development  leads  to  delayed  schedules,  unexpected  costs,  or  the  creation  of  a  product 
that  does  not  meet  requirements.  Loss  of  control  during  operations  could  result  in  user 
frustration,  unsustainable  TOC,  or,  in  the  worst  cases,  injury  or  death  (Stark,  2005). 

It  is  important  to  note  that  collaborative  PLM  is  not  a  definition  of  a  piece  (or 
pieces)  of  technology  (Figure  4).  It  is  a  business  approach  that  can  align  and  increase  the 
efficiency  and  effectiveness  of  activities  by  leveraging  software  applications  and  process 
improvements.  In  this  respect,  it  is  more  of  a  strategy  than  a  system.  As  a  strategy,  not  a 
system,  collaborative  PLM  can  be  configured  to  meet  the  unique  aspects  of  any 
organization.  A  company  can  invest  in  as  many  or  as  few  collaborative  PLM 
components  as  necessary  to  meet  their  unique  needs.  This  eases  the  hindrance  of  a  large 
capital  investment  as  well  as  allows  organizations  to  focus  on  one  area  at  a  time  and  not 
become  overwhelmed  by  trying  to  change  too  much  at  once. 
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Figure  4.  Collaborative  PLM  Across  the  Lifecycle 


In  the  following  section,  we  can  examine  how  two  technical  publications  have 
tried  to  answer  the  question  “What  is  collaborative  PLM?” 

CIMdata  (“Product  Lifecycle  Management,”  n.d.),  an  independent  PLM 
consulting  firm,  defined  PLM  as, 

A  strategic  business  approach  that  applies  a  consistent  set  of  business  solutions 
that  support  the  collaborative  creation,  management,  dissemination,  and  use  of 
product  definition  information  across  the  extended  enterprise  from  concept  to  end 
of  life  of  a  product  or  plant-  integrating  people,  processes,  business  systems,  and 
information,  (p.  1) 

A  second  definition  comes  from  CIO  Magazine,  a  publication  whose  mission  is  to 
provide  technology  and  business  leaders  with  insight  and  analysis  on  information- 
technology  (IT)  trends.  CIO  magazine  (2003)  stated  the  following  about  the  evolution  of 
PLM  and  its  role  in  achieving  business  goals: 

Product  lifecycle  management  is  an  integrated,  information-driven  approach  to  all 
aspects  of  a  product’s  life,  from  its  design  through  manufacture,  deployment,  and 
maintenance,  culminating  in  the  product’s  removal  from  service  and  final 
disposal.  PLM  software  suites  enable  accessing,  updating,  manipulating,  and 
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reasoning  about  product  infonnation  that  is  being  produced  in  a  fragmented  and 
distributed  environment.  Another  definition  of  PLM  is  the  integration  of  business 
systems  to  manage  a  product’s  lifecycle.  (Stackpole,  2003,  p.  1) 

There  is  a  common  theme  between  these  two  definitions:  By  creating,  sharing,  and  using 
all  forms  of  product  related  information,  we  can  trade  infonnation  for  wasted  time, 
energy,  and  material  to  ensure  the  most  efficient  use  of  physical  resources. 

Collaborative  PLM  can  help  manage  a  product  better,  but  the  real  benefit  is  that  it 
strives  to  manage  all  products  better  in  a  fully  integrated  portfolio.  Dan  Billingsley  has 
over  30  years  of  acquisition  experience:  When  asked  his  view  on  DoD  acquisition,  he 
argued  that  the  structure  has  become  heavily  product  centric,  with  too  much  focus  given 
to  the  perfonnance  of  the  product,  while  forgetting  how  we  got  to  that  particular  point  (D. 
Billingsley,  personal  communications,  April  5,  2010).  He  argued  that  we  need  to  leam 
from  our  successes  as  well  as  our  failures  and  fix  the  practices  and  processes  used  during 
the  lifecycle,  in  order  to  ensure  the  entire  portfolio  is  successful.  Collaborative  PLM 
offers  a  way  to  restore  the  balance  because  it  emphasizes,  “how  a  business  works,”  just  as 
much  as,  “what  is  being  created”  (CIMdata,  n.d.). 

The  following  paragraph  from  Product  Lifecycle  Management  by  Anitti 
Saaksvuori  and  Ansehni  Immonen  (2008)  perfectly  answers  the  question,  “What  is 
PLM?”: 


PLM  is  an  organized,  controlled  strategy  for  developing  and  then 
managing  products  and  all  their  associated  information.  The  central  theme 
of  PLM  is  the  creation,  preservation,  and  storage  of  information  relating  to 
the  company’s  products  and  activities,  in  order  to  ensure  the  fast,  easy  and 
trouble-free  finding,  refining,  distribution  and  reutilization  of  the  data 
required  for  daily  operations.  In  other  words,  work  that  has  been  done 
should  remain  exploitable,  regardless  of  place,  time,  or — within  prescribed 
limits,  naturally — data  ownership.  At  the  same  time,  the  idea  is  to  convert 
data  managed  by  a  company’s  employees,  skilled  persons  and  specialists 
into  company  capital  in  an  easily  manageable  and  sharable  form.  (p.  32) 

Collaborative  PLM  can  help  improve  the  productivity  across  the  defense 
acquisition  community  by  capturing  and  using  data  the  first  time  it  is  created.  Time 
previously  wasted  searching  for  or  recreating  product  data  can  be  spent  collaborating 
with  other  experts  on  how  to  improve  the  product. 
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C.  PRINCIPLES  BEHIND  THE  PLM  STRATEGY 

1.  Focus  on  the  Product 

The  shipbuilding  industry  is  a  product-focused  business,  meaning  the  portfolio 
may  contain  many  variants  of  a  single  product  line,  each  with  similar  specifications, 
parts,  drawings,  manufacturing  techniques,  or  operations,  as  opposed  to  an  assembly  line 
organization  that  chums  out  an  indefinite  quantity  of  one  identical  product.  These 
variants  could  be  different  building  blocks  of  either  the  same  class,  or  common 
components  or  systems  across  all  classes.  The  benefits  of  the  collaborative  PLM  strategy 
are  realized  when  lessons  learned  from  the  first  generation  are  applied  to  all  subsequent 
generations,  in  order  to  decrease  their  cost  and  time  for  development.  The  second 
generation  may  reuse  75%  of  the  parts  from  the  previous  generation,  decreasing  the  time 
and  resources  spent  designing  and  verifying  the  second  generation  design  (Stark,  2005). 

Co-locating  experts  with  diverse  backgrounds  as  members  of  the  design  team  has 
benefits  to  the  program.  Teams  with  representatives  from  marketing,  design, 
engineering,  operations,  manufacturing,  service,  testing,  quality,  and  logistics  can  make 
better  collective  decisions,  reducing  bottlenecks,  rework,  and  wait  times  by  sharing 
knowledge.  With  each  iteration,  the  collective  knowledge  expands,  to  the  benefit  of 
future  projects.  The  teams’  combined  knowledge  of  design,  process,  material, 
manufacturing,  quality,  and  customer  requirements  enables  them  to  deliver  first-time 
quality  in  a  product,  a  product  that  has  a  better  fit  to  customer  needs,  reduced  costs,  and  a 
faster  to-market  time.  While  collocation  is  preferred,  sometimes  it  is  not  feasible  to 
collocate  the  people  that  have  the  authority  to  make  decisions.  Collaborative  PLM  gives 
organizations  the  ability  to  gain  some  of  the  same  benefits  through  its  collaboration  tools. 

2.  Collaborative  PLM  Involves  Customers  by  Listening  to  Feedback 

It  is  important  to  listen  to  the  customer  and  ensure  that  the  requirements, 
expectations,  features,  and  wishes  are  reflected  in  the  delivered  product,  but  listening  to 
the  customer  is  the  minimum.  A  better  solution  is  to  involve  the  customer  directly  in  the 
design  from  the  very  beginning.  With  a  customer  empowered  to  make  decisions  as  a 
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member  of  the  cross-functional  team,  problems  can  be  identified  sooner,  thus  avoiding 
expensive  rework  or,  worse,  resolving  the  problem  too  late,  leading  to  an  unsatisfied 
customer. 

Another  way  to  gain  valuable  insight  from  the  customer  is  by  receiving  feedback 
on  fielded  products.  Customers  may  be  frustrated  that  a  particular  system  is  not  operating 
as  expected,  or  they  may  need  help  completing  a  particular  piece  of  maintenance. 
Helping  operators  with  these  frustrations  can  give  designers  ideas  about  how  to  improve 
the  product  further.  The  designers  can  capture  this  knowledge  and  make  sure  it  is 
reflected  in  the  follow-on  design. 

Sensors  can  capture  feedback  directly  from  the  product.  Maintainers  will  be  able 
to  monitor  products  to  trace  when  a  particular  system  begins  operating  out  of  the  normal 
operating  range  and  trouble  shoot  if  its  operators  need  training  or  if  the  system  needs 
maintenance.  Designers  will  be  able  to  detennine  if  a  particular  system  was  over¬ 
engineered  or  can  be  optimized  for  actual  operations. 

3.  Collaborative  PLM  Offers  More  than  Cost  Savings 

The  unsustainable  trend  of  cost  escalation  is  one  of  the  main  drives  for 
undertaking  acquisition  reform.  Money  is  a  finite  resource,  and  the  lack  of  money  is 
forcing  program  managers  to  take  a  hard  look  at  the  business  model  to  determine  how 
things  can  be  done  better.  However,  it  is  important  to  remember  that  a  goal  to  solely 
minimize  cost  is  shortsighted.  Programs  are  not  started  because  they  are  the  cheapest,  but 
because  warfighters  have  needs  and  new  products  have  the  ability  to  meet  their  needs. 

During  an  interview,  Ron  Watson,  global  product  data  manager  for  ITT 
Industries,  commented  that: 

Restricting  the  focus  to  cost  reduction,  what  you’re  essentially  doing  is 
sacrificing  the  needs  and  the  functions  needed  by  the  customer.  [...]  The 
greatest  value  is  really  a  function  of  [delivering]  what  the  customer  wants, 
and  cost  is  just  something  that  you  try  to  drive  down.  [...]If  you  use  just 
cost  as  an  arbitrary  determining  factor,  then  you're  limiting  yourself. 
(Teresko,  2004a,  p.  1) 


19 


Any  changes  recommended  for  the  Navy’s  strategy  must  be  focused  on  delivering 
increased  value  to  the  warfighter,  not  endlessly  chasing  cost  reductions. 

4.  Implementing  Processes,  Techniques,  Methodology 

Various  techniques  have  been  used  successfully  to  carry  out  product 
developments  and  support  more  effectively.  One  of  the  challenges  of  collaborative  PLM 
is  providing  structure  to  techniques  capable  of  assisting  with  organizational  goals.  Table 
3  is  a  list  of  just  a  few  of  the  processes  that  have  been  implemented  by  organizations 
through  a  collaborative  PLM  system. 


Table  3.  Representative  Processes  Incorporated  into  PLM 

(After  Stark,  2005) 


Concurrent  Engineering 


Technique  to  bring  together  multidisciplinary  teams  that  work  from  the  start  of  a  development 
project  with  the  aim  of  getting  things  right  as  quickly  as  possible,  and  as  early  as  possible. 


Configuration  Management 


The  activity  of  documenting  initial  product  specifications  and  controlling  and  documenting  changes 
to  these  specifications.  A  formal  discipline  to  help  assure  the  quality  and  long-term  support  of 
complex  products  through  consistent  identification  and  effective  monitoring  and  control  of  all  the 
information. 


Design  for  Assembly 


Techniques  aimed  at  reducing  the  cost  and  time  of  assembly  by  simplifying  the  product  and  process 
through  such  means  as  reducing  the  number  of  parts,  combining  part  functions,  reducing  or 
eliminating  adjustments,  simplifying  assembly  operations,  designing  for  parts  handling,  and  ensuring 
products  are  easy  to  test. 


Lifecycle  Assessment 


Methodology  used  to  understand  the  main  impacts  arising  in  each  phase  of  a  product's  lifecycle. 


Portfolio  Management 


Technique  allowing  managers  to  make  tradeoff  decisions  based  on  risk/rewards  of  the  product 
portfolio  against  an  organization's  strategic  objectives. 


Process  Mapping 


Methodology  carried  out  to  understand,  design,  and  analyze  business  processes. 


Quality  Function  Deployment(QFD) 


A  step-by-step  technique  for  ensuring  that  the  voice  of  the  customer  is  heard  throughout  the 
product-development  process  so  that  the  final  product  fully  meets  customer  requirements. 
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5.  Integrating  Modern  Components,  Applications,  Systems 

Collaborative  PLM  is  a  new  concept  that  relies  on  the  capability  of  several 
complex  technologies.  Collaborative  PLM  is  not  a  new  tool,  nor  does  it  strive  to  replace 
the  tools  you  already  have.  Collaborative  PLM  is  an  effort  to  take  those  concepts  and 
technologies  that  have  existed  on  their  own,  and  integrate  them  together,  providing  a 
comprehensive  understanding  of  the  product.  The  manner  in  which  these  tools  and 
technologies  are  integrated  allows  productivity  gains  that  could  not  be  experienced  if  you 
were  running  all  of  the  same  tools  independently.  One  of  the  challenges  of  PLM  is  to 
identify  system  components  that  are  aligned  with  company  goals  and  understand  how 
they  fit  into  a  collaborative  PLM  system.  We  will  explore  four  of  the  foundational 
components  of  a  collaborative  PLM  system:  computer-aided  design  (CAD),  engineering 
data  management  (EDM),  product  data  management  (PDM),  and  computer-integrated 
manufacturing  (CIM). 


a.  Computer-Aided  Design 

Computer-aided  design  (CAD)  refers  to  an  application  that  can  represent 
physical  products  using  math-based  descriptions  to  locate  and  consistently  replicate 
shapes  in  either  two  or  three  dimensions  (Figure  5).  CAD  models  have  the  ability  to 
improve  quality  and  reduce  developmental  time  and  costs.  Precision  is  only  limited  by 
the  capabilities  of  the  CAD  application.  Each  replication  will  be  identical  every  time,  and 
measurements  will  be  consistent,  regardless  of  who  is  taking  the  measurements.  Because 
the  object  can  be  rotated  and  displayed  from  various  angles  and  zoomed  in  to  see  details, 
users  can  find  errors  more  quickly  and  can  correct  them  immediately. 

The  progression  from  two-dimensional  to  three-dimensional  drawing 
makes  virtuality  and  computer-aided  engineering  (CAE)  possible.  CAE  refers  to  the 
extract  data  from  the  model  and  performs  analyses  and  simulations,  testing  things  like 
structural  integrity  and  perfonnance.  Simulation  delivers  insight  into  the  performance  of 
a  system’s  product  of  process  before  it  has  been  built.  Once  the  model  is  developed,  it 
can  be  inserted  into  an  artificial  environment  to  analyze  a  system’s  behavior  under 
various  conditions.  From  this  analysis,  errors  can  be  corrected,  tradeoffs  can  be 
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evaluated,  and  designs  can  be  optimized.  Simulation  allows  a  continuous  stream  of 
“what  ifs”  to  be  considered,  without  the  costs  and  time  needed  to  build  physical 
prototypes. 


Figure  5.  3D  Solid  Versus  Wireframe  CAD  Model 

(From  General  Dynamics  Electric  Boat,  2002) 


Once  built,  the  component  can  be  reused  throughout  the  design  without  having  to  be 
recreated.  Once  released,  other  products  can  reuse,  update,  or  modify  it  to  fit  future 
needs.  Stakeholders  can  evaluate  the  model  and  accept  or  suggest  modifications, 
improving  the  design  without  waiting  for  a  prototype. 

b.  Engineering  Data  Management 

The  models  built  in  CAD  applications  describe  the  products  geometrically, 
but  for  a  complete  description,  they  must  be  augmented  by  other  information  or 
characteristics.  These  characteristics,  to  complete  the  description,  could  be  any  kind  of 
information,  such  as  tolerances,  tensile  strength,  weight  restrictions,  adhesives, 
conductivity  requirements,  the  process  for  assembly,  the  methodology  for  coating  or 
painting,  or  testing  requirements  or  procedures,  to  name  a  few  (Grieves,  2006). 

This  type  of  information  was  the  focus  behind  developing  engineering 
data  management  (EDM).  A  positive  aspect  is  that  there  is  one  program  that  is  used  by 
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the  majority  of  engineers  to  track  this  information;  thus,  distribution  and  access  is  easier. 
A  negative  aspect  is  that  this  program  is  Microsoft  Excel,  which  has  an  infinite  number  of 
ways  it  can  be  customized  and  presented.  While  this  flexibility  has  allowed  engineers  to 
personalize  their  files  for  optimal  personal  productivity,  organizational  productivity 
suffers  because  each  new  user  has  to  go  through  a  learning  curve  every  time  a  new  file  is 
used.  Extensive  reorganization  needs  to  occur,  taking  the  extensive  data  known  by 
individuals  and  making  it  accessible  to  the  entire  organization. 

c.  Product  Data  Management 

Product  data  management  (PDM)  is  a  primary  component  of  a 
collaborative  PLM  solution  and  is  designed  to  provide  the  right  information,  at  the  right 
time,  to  the  right  person.  PDM  is  needed  as  a  means  to  organize  and  catalog  the  CAD 
and  EDM  information.  Once  the  data  is  in  the  systems,  it  can  be  accessed  by  anyone 
with  the  appropriate  permission,  anytime  and  anywhere.  Data  does  not  get  lost,  and  it 
will  not  be  damaged.  The  data  in  the  systems  will  not  be  an  outdated  copy,  and  it  will  not 
be  unavailable  because  someone  else  has  it.  Once  all  the  data  is  linked,  if  a  source 
document  changes,  notifications  will  be  made  to  all  those  affected  so  that  everyone  and 
everything  stay  on  the  same  page.  Product  data  is  a  strategic  resource  that  influences 
decisions.  Therefore,  the  data  must  be  under  control,  before  the  product  can  be 
controlled. 

The  functionality  of  a  PDM  system  can  be  grouped  into  two  categories: 
user  functions  and  utility  functions.  The  user  functions  provide  the  functionality  for  the 
users  to  interact  with  the  database  and  can  be  grouped  in  the  following  subcategories: 

1 .  Data  vault  and  document  management, 

2.  Workflow  and  process  management, 

3.  Product  structure  management, 

4.  Classification  management,  and 

5.  Program  management  (Crnkovic,  Dahlqvist,  &  Asklund,  2003). 

The  utility  functions  provide  the  ability  for  the  data  to  interface  between 

different  operating  environments  and  can  be  grouped  into  the  following  subcategories: 

1 .  Communication  and  notification, 

2.  Data  transport  and  translation, 
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3.  Image  services, 

4.  Administration,  and 

5.  Application  integration  (Crnkovic  et  al.,  2003). 
d.  Computer-Integrated  Manufacturing 

Computer-aided  manufacturing  (CAM)  is  the  idea  that  CAD  files  can  be 
used  to  generate  programs  to  control  and  sequence  automated  manufacturing  machines. 
Computer-integrated  manufacturing  (CIM)  goes  a  step  further,  and  focuses  on  the 
advantages  of  sharing  infonnation  across  function  areas  of  an  organization.  CIM 
represents  the  idea  that  a  computer  system  could  integrate  the  functions  necessary  to 
design,  engineer,  and  manufacture  a  product. 

Rapid  prototyping  is  the  construction  of  a  physical  prototype  directly  from 
the  computer  model.  A  physical  prototype  can  be  tested  to  validate  the  accuracy  of  the 
computer  models,  check  interference,  and  evaluate  ease  of  assembly  and  maintenance.  In 
the  traditional  prototyping  process,  a  design  is  produced  and  then  sent  to  manufacturing 
engineers,  who  then  figure  out  how  to  build  it.  The  manufacturing  department  has  often 
had  to  recreate  data  that  was  available  in  engineering,  but  was  never  transferred  so  that  it 
could  modify  the  design  into  something  buildable.  After  this  process  of  recreating  data,  a 
model  was  built.  With  rapid  prototyping,  the  physical  model  can  be  produced  directly  by 
one  of  the  rapid-prototyping  applications,  saving  time  and  possible  transcription  errors  or 
misinterpretations  from  engineering  to  manufacturing.  Closing  the  information  loop 
between  engineering  and  manufacturing  will  help  correct  one  of  the  most  inefficient 
elements  of  engineering,  the  fact  that  often,  a  design  is  “thrown  over  the  wall”  to  where 
manufacturing  has  to  figure  out  if  and  how  to  build  it. 

6.  Collaborative  PLM  Continuously  Strives  to  Increase  Value,  Quality, 
and  Reduce  Cycle-Time  and  Costs 

The  organization  must  be  structured  in  a  manner  that  focuses  on  always  providing 
its  customers  with  products  and  services  that  satisfy  their  needs.  By  eliminating  defects 
and  reducing  waste  first-time  quality  can  be  achieved. 
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Cycle-time  reduction  should  be  a  major  focus.  The  product  was  created  to  satisfy 
a  capability  gap  of  the  warfighter;  thus,  the  sooner  that  gap  is  closed  the  better.  In 
addition,  the  sooner  the  product  is  in  use,  the  sooner  feedback  can  be  applied  to  a  new 
and  improved  version.  When  it  comes  to  rapidly  evolving  technology,  if  the  cycle-time  is 
too  long,  what  began  in  the  design  process  as  cutting  edge  could  be  obsolete  by  the  time 
it  is  in  operation.  Shorter  cycle-time  not  only  ensures  the  technology  gets  to  the 
warfighter  while  it  is  still  relevant,  but  also  supports  the  evolutionary  approach  in  which 
new  technology  can  be  inserted  into  the  latest  model.  Finally,  shorter  cycle-times  lead  to 
increased  flexibility  and  experience  for  the  design  organization.  As  the  threats  evolve, 
having  a  design  team  that  is  not  invested  in  designing  the  weapon  for  the  previous  war 
will  keep  the  organization  agile.  In  a  given  time  period,  a  shorter  cycle-time  results  in  a 
greater  number  of  cycles;  meaning,  the  more  times  a  team  does  something,  the  better 
they  will  become. 

D.  WHAT  IS  THE  NEED  FOR  PLM? 

This  section  will  look  at  some  of  the  driving  forces  behind  the  need  for 
collaborative  PLM,  and  reasons  why  the  previous  technologies  and  procedures  are  not 
sufficient  in  the  current  environment.  The  Navy  is  not  alone  in  its  need  to  improve  its 
business  model.  Indeed  the  same  thing  drives  other  companies:  the  need  to  create  value 
and  improve  productivity,  the  rate  of  innovation,  collaboration,  and  quality  (Grieves, 
2006). 


1.  Maximizing  Productivity 

Productivity  for  an  organization  refers  to  the  ratio  of  outputs  received  while 
expending  a  given  set  of  inputs  or  resources.  The  private  sector  focuses  on  striving  to 
improve  productivity,  which  it  hopes  translates  into  improved  profitability.  The 
government  does  not  turn  a  profit,  per  se,  but  productivity  is  still  critical  because  there 
are  never  enough  dollars  to  fund  every  need,  and  the  ability  for  government  programs  to 
make  the  best  use  of  the  funds  available,  frees  money  to  allocate  to  other  needs. 

A  1994  Cooper  and  Lybrand  study  broke  down  the  typical  day  of  an  engineer 

(Figure  6).  The  study  showed  that  about  24%  of  time  was  spent  looking  for,  distributing, 
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or  maintaining  information.  The  engineers  also  indicated  that  rather  than  search  for  data 
it  was  easier  and  quicker  to  just  redo  work  that  had  already  been  completed  previously; 
redoing  work  accounted  for  21%  of  the  time.  Another  14%  of  the  time  was  spent  in 
meetings,  where  engineers  were  either  updating  or  being  updated  on  progress  (Saaksvuori 
&  Immonen,  2008).  This  study  indicated  that  there  is  a  tremendous  opportunity  to 
improve  the  productivity  of  the  typical  engineer. 


Figure  6.  The  Engineer’s  Use  of  Time 

(After  Saaksvuori  &  Immonen,  2008) 


Collaborative  PLM  offers  the  ability  to  positively  impact  productivity  by 
leveraging  information  to  eliminate  wasted  time,  especially  the  time  spent  searching  for 
data,  by  utilizing  simulations  to  discover  the  most  efficient  workflow,  and  by  facilitating 
the  reuse  of  designs  that  would  normally  be  recreated. 

2.  Cultivate  Innovation 

Innovation  is  a  change  in  the  thought-process  for  doing  something.  It  may  refer  to 
incremental,  emergent,  or  radical  and  revolutionary  changes  in  thinking,  products, 
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processes,  or  organizations.  These  changes  could  be  new  inventions,  such  as  the 
automobile  or  computer,  or  they  could  be  new  approaches,  such  as  the  assembly  line  or 
LEAN  manufacturing.  All  these  examples  have  changed  the  way  things  are 
accomplished  in  their  respective  disciplines.  When  Michael  Grieves  delineated  the 
different  goals  of  productivity  and  innovation,  his  position  is  that  while  productivity 
focuses  on  costs,  innovation  focuses  on  adding  value  for  the  stakeholder.  Taking  his 
point  about  integration  further,  he  asserted  that  innovation  is  another  major  driver  behind 
collaborative  PLM,  one  that  can  be  subdivided  into  (1)  product  innovation  and  (2) 
workflow  innovation  (Grieves,  2006). 

The  first  kind  of  innovation,  i.e.,  product  innovation,  refers  to  improving  some 
characteristic  of  the  product,  such  as  new  technology  or  new  features.  These  things 
create  value  for  the  users  by  reducing  the  time,  energy,  and  materials  required  to  perform 
tasks  or  by  making  it  possible  to  perform  tasks  that  were  previously  impossible.  An 
example  of  product  innovation  would  be  the  USS  Nautilus  (SSN  571)  the  first  nuclear 
submarine,  which  could  remain  submerged  for  up  to  four  months,  a  feat  previously 
unachievable,  this  capability  made  new  missions  possible  and  transformed  the  submarine 
force  (Smithsonian  Institution,  n.d.).  Collaborative  PLM  cannot  deliver  any  new 
innovative  ideas  but  can  free  engineers  from  menial  tasks  and  allow  them  to  focus 
innovation.  Through  collaboration  with  the  stakeholders,  PLM  helps  raise  visibility  of 
what  the  customer  values  in  order  to  limit  product  innovation  to  only  the  value-added 
items.  The  users  will  detennine  what  is  a  desire  and  what  is  a  need  to  help  guide  the 
design  effort.  For  instance,  if  the  Navy  “needs”  a  ship  that  can  go  35  knots,  it  may  not  be 
willing  to  pay  the  extra  cost  to  design  a  ship  that  can  go  50  knots.  By  failing  to  listen  to 
the  customer,  there  is  a  risk  of  expending  resources  on  non  value-added  features. 

The  actual  task  of  innovation  does  not  occur  without  human  skill,  talent,  and 
creativity.  The  collaborative  PLM’s  role  is  to  enhance  this  effort  by  ensuring  the  right 
information  is  accessible  when  and  where  it  is  needed.  Innovation  also  requires 
resources.  The  ability  of  collaborative  PLM  to  reduce  wasted  time,  material,  and  energy 
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through  activities  such  as  eliminating  redundant  activities  or  decreasing  time  searching 
for  information  will  help  ensure  that  more  resources  are  available  to  focus  on  value- 
added  innovation  tasks. 

Workflow  innovation  is  the  second  kind  of  innovation,  and  unlike  product 
innovation,  it  focuses  on  finding  better  methods  and  technologies  to  reduce  the  time, 
energy,  and  material  needed  to  produce  the  product.  For  instance,  Henry  Ford  created  the 
assembly  line  to  build  his  automobiles.  As  a  result,  his  more  effective  methods  created 
savings,  making  automobiles  much  more  affordable;  this  not  only  changed  how 
automobiles  were  constructed  but  also  influenced  the  processes  of  many  other  industries. 
The  majority  of  the  recommendations  contained  in  this  research  deal  with  workflow 
innovation.  This  approach  was  chosen  because  an  improved  workflow  has  the  ability  to 
improve  the  entire  portfolio  of  programs,  while  product  innovation  is  more  specific  to  a 
particular  capability.  We  will  be  searching  for  workflow  innovation  that  the  Navy  can 
apply  to  ensure  that  the  most  efficient  use  of  resources  is  being  made. 

3.  Improve  Collaboration 

Collaboration  is  where  two  or  more  people  or  organizations  work  together  in  an 
intersection  of  common  goals.  For  example,  an  intellectual  endeavor  is  collaborative  and 
creative  in  nature  when  numerous  people  share  knowledge,  learning,  and  build 
consensus.  As  project  teams  today  are  rarely  located  under  one  roof,  the  need  to 
effectively  collaborate  must  be  enabled  by  technologies  that  connect  people  across 
geographical  distances,  organizational  borders,  and,  more  frequently,  national  borders. 
The  collaborative  PLM  contribution  to  collaboration  is  the  ability  to  colocate  in  virtual 
time  and  space,  people  who  otherwise  would  not  be  able  to  be  together  geographically  or 
temporally. 

Social  networking  is  a  form  of  collaboration  adding  new  dimensions  to  the  way 
that  people  interact  within  their  network  of  friends.  The  latest  versions  of  collaborative 
PLM  have  embraced  these  social  computing  capabilities  to  take  advantage  of  these 
collaborative  techniques,  creating  “corporate  social  networks”  that  tie  together 
communities  around  a  common  business  goal  (Brown  J.,  2009). 
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Features  such  as  instant  communication  and  sharing — including  alerts, 
subscriptions,  instant  messaging,  status  updates,  and  other  techniques — help  people 
instantly  contribute  to  the  ongoing  product  development  dialogue.  Chat  and  presence 
detection  help  bring  communities  together  in  real-time  to  share  ideas  and  solve  problems, 
answering  questions  that  would  otherwise  be  saved  for  later,  forgotten,  or  ignored.  This  is 
particularly  important  during  the  early  phases  of  a  project  when  interactions  are  more 
frequent  and  results  are  less  fonnal. 

These  new  social  capabilities  go  beyond  traditional  collaboration,  which  generally 
occurs  between  people  who  already  know  each  other.  These  social  capabilities  build  on 
what  is  referred  to  as  social  discovery.  Social  discovery  involves  finding  others  in  the 
corporate  network  that  may  have  relevant  expertise,  similar  to  how  the  Internet-based 
popular  network  Facebook  recommends  friends.  Through  the  network,  colleagues  who 
may  never  have  met  may  contact  each  other,  and  can  build  upon  their  collective 
knowledge  base.  Corporate  social  networking  is  a  new  feature  of  collaborative  PLM 
applications,  and  based  on  how  it  matures,  has  potential  to  facilitate  innovation  and  help 
enhance  collaboration  (Brown  J.,  2009). 

The  USS  Virginia  program  used  teleconferencing  (Figure  7)  to  have  long-distance 
reviews/discussions  of  the  evolving  Virginia  Class  design  on  a  regular  basis.  The 
teleconferencing  system  used  in  the  program  allows  reviewers  at  a  distance  and  in  real 
time  to  see  engineering  models  of  the  design,  including  the  3D  virtual  reality  model  of 
the  ship  arrangement.  During  sessions,  the  Navy  participants  in  Washington,  DC,  were 
able  to  request  changes  in  the  3D  model  (being  executed  in  Connecticut),  question  the 
location  of  certain  items,  and  see  how  certain  items  could  be  removed  and  accessed 
(General  Dynamics  Electric  Boat,  2002).  As  this  example  shows,  the  ultimate  end  state 
of  collaborative  PLM  is  to  be  capable  of  capturing  enough  data  about  a  product  that  the 
virtual  product  is  indistinguishable  from  the  physical,  and  the  richness  of  communication 
makes  virtual  communication  just  as  effective  as  face-to-face  contact. 
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Figure  7.  Virtual  Collaboration  on  USS  Virginia  During  Weekly  Teleconference 

(From  General  Dynamics  Electric  Boat,  2002) 

4.  Need  to  Develop  Quality 

There  exist  two  main  aspects  of  quality:  first,  the  product  must  meet  its 
specifications;  second,  the  product  must  perform  to  a  particular  standard  of  usage 
(Grieves,  2006).  A  product  that  lacks  quality  will  at  best  result  in  wasted  time,  material, 
and  require  energy  to  repair  it,  and  at  worst,  it  could  cause  injury  or  death. 

Products  that  fail  to  meet  their  specifications  must  be  scrapped,  reworked,  or 
repaired,  consuming  resources  that  could  otherwise  be  applied  to  value-added  activities. 
If  the  designer  or  supplier  has  confusion  or  misunderstandings  concerning  the 
specifications,  then  there  is  a  greater  chance  that  the  product  will  fail  to  meet  the  intended 
specifications.  Collaborative  PLM  offers  a  constant  and  singular  view  of  product  data  to 
help  remove  any  uncertainty  about  product  specification,  and,  as  described  before,  the 
collaboration  allows  the  building  of  a  consensus  while  in  the  virtual  world,  before  any 
physical  delays  can  be  experienced. 
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When  looking  at  the  complexity  of  the  products  being  created  and  realizing  that 
the  operating  environment  is  equally  complex,  it  is  easy  to  justify  extensive  testing  to 
ensure  products  can  meet  usage  requirements.  Traditionally,  extensive  and 
comprehensive  testing  in  various  states  under  various  conditions  was  required, 
consuming  excessive  resources.  Collaborative  PLM  can  assist  by  conducting  a  majority 
of  tests  in  the  virtual  world  for  substantially  less  time  and  money,  and  because  a  physical 
prototype  is  not  required,  collaborative  PLM  can  test  many  more  options  than  physical 
testing  (Grieves,  2006).  Dassault  Systems  collaborative  PLM  system  V6  has  the  ability 
to  conduct  virtual  maintenance  (Figure  8).  This  feature  not  only  measures  the 
ergonomics  of  the  workers,  in  order  to  verify  the  task  can  be  accomplished  safely,  but 
also  enables  the  worker  to  see  everything  that  needs  to  be  seen,  and  shows  that  all  tasks 
are  physically  possible  (Dassault  Systems,  2010).  This  is  an  example  of  how  problems 
can  be  identified  and  corrected  in  the  virtual  world,  where  the  impact  to  the  program  is 
negligible. 


Figure  8.  Images  Demonstrating  Virtual  Maintenance 

(From  Dassault  Systems,  2010) 


5.  Current  Life  Cycle  Environment  Lacks  Control 

An  aspect  of  properly  managing  product  data  in  the  product-lifecycle  environment 
means  not  allowing  the  data  collected  to  sit  in  a  virtual  file  cabinet  and  become  a  giant 
repository,  collecting  dust  without  providing  any  benefits.  The  data  being  created, 
collected,  integrated,  and  used  during  a  program,  and  made  available  in  a  virtual  library 
could  be  as  follows:  customer  requirements,  design  specifications,  process  models, 
drawings,  assembly  drawings,  analytic  models,  simulation  results,  parts  list,  tools  and 
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fixture  designs,  mounting  instructions,  process  plans,  bills  of  material,  configuration 
drawings,  CAD  geometry,  status  reports,  maintenance  history,  and  requirements,  to  name 
a  few. 

A  potential  problem  with  managing  the  different  types  of  product  data  is  the  large 
number  of  people  who  use  product  data  through  the  lifecycle,  including  members  of 
various  departments  inside  an  organization,  suppliers,  contractors,  maintainers,  users,  and 
so  on.  Each  needs  access  to  the  data  to  support  the  product;  however,  at  the  same  time, 
the  data  also  needs  to  be  protected  from  those  who  should  not  have  access.  As  the 
repository  of  product  data  grows,  so  can  wasted  efforts;  developers  may  waste  time 
searching  through  various  databases,  having  to  navigate  through  the  mass  of  existing 
designs  to  find  a  specific  piece  of  data.  Studies  have  shown  that  design  engineers  spend 
up  to  80%  of  their  time  on  administrative  and  information-retrieval  activities  (Stark, 
2005).  If  the  data  found  is  an  outdated  version,  rework  could  be  required  to  correct 
discrepancies.  When  the  existing  design  cannot  be  found,  the  data  is  usually  recreated, 
resulting  in  unnecessary  costs. 

As  more  and  more  data  is  generated,  the  task  of  controlling  it  becomes  more 
overwhelming.  CAD  drawings  are  just  one  piece  from  the  list  of  product-data  types 
mentioned  previously.  A  submarine’s  plans  can  easily  exceed  100,000  drawings  (Stark, 
2005).  Think  of  a  single  CAD  drawing  as  one  piece  of  a  100,000  piece  puzzle:  as  the 
designer  completes  the  drawing,  it  is  stored  in  the  project  data  base  with  all  the  other 
drawings,  simply  thrown  into  the  box  of  puzzle  pieces.  What  happens  if  a  particular 
piece  is  needed  later?  How  long  could  it  take  to  sort  through  the  box  to  find  the 
particular  piece?  When  the  file  is  needed  and  cannot  be  found,  it  must  be  recreated, 
usually  in  a  rush,  and  will  likely  be  less  thorough  than  the  original,  opening  the  potential 
for  more  errors.  Just  because  the  particular  file  could  not  be  found  before  making  the 
decision  to  recreate  it  does  not  mean  that  it  is  not  actually  in  the  system.  And  now,  the 
puzzle  has  two  of  the  same  pieces,  causing  problems  later.  Each  time  this  cycle  repeats, 
another  version  of  a  file  enters  the  system,  and  the  likelihood  that  work  will  be 
progressed  based  on  data  from  an  out-of-date  document  is  increased.  This  cycle  is  how 
the  lack  of  reliable  configuration  management  introduces  more  errors  and  waste. 
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Figure  9.  Enhanced  3D  Product  Model 

(From  Siemens  PLM  Software  (Team  Center),  2008) 


Collaborative  PLM  addresses  this  issue  by  having  integrated  all  the  product  data. 
For  instance,  through  the  3D  model  (Figure  9),  a  user  can  click  on  a  particular  component 
and  the  data  fields  will  show  every  piece  of  product  data  associated  with  that  component. 
Additionally,  with  the  appropriate  links  established,  if  that  part  changes,  the  stakeholders 
of  other  affected  components  are  notified.  For  example,  if  one  of  the  puzzle  pieces  is 
changed,  the  owners  of  the  surrounding  puzzle  pieces  will  be  notified  in  case  their  pieces 
must  also  be  changed.  This  prevents  problems  that  may  otherwise  go  unnoticed  until 
much  later  in  the  process. 

E.  BENEFITS  ALONG  THE  LIFECYCLE 

Organizations  are  often  metrics  based,  and  prior  to  making  a  major  shift  in 
strategy,  the  metrics  must  justify  the  value  of  that  shift.  This  has  justified  program 
managers  in  making  decisions  that  affect  today’s  bottom  line,  while  disregarding  the 
effect  on  the  lifecycle.  Collaborative  PLM  will  make  the  full  impact  of  these  decisions 
visible  sooner  to  correct  this  behavior.  When  decisions  are  made  that  consider  the  entire 
lifecycle,  sometimes  the  benefits  are  not  easily  traced  back  to  a  particular  decision,  and 
sometimes  they  will  not  occur  in  the  same  phase.  They  will  often  overlap  or  appear  in 
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different  forms  (i.e.,  cost,  schedule,  or  functionality).  However,  when  the  product  is 
under  control,  there  will  be  benefits.  The  following  chapters  will  introduce  case  studies 
and  specific  examples  of  how  the  DoD  portfolio  could  benefit  by  modifying  its  processes, 
to  correct  deficiencies  and  take  full  advantage  of  capabilities  possible  with  a  collaborative 
PLM  suite.  The  following  is  a  list  compiled  by  Softech  and  John  Stark  (2007)  of 
potential  benefits  with  collaborative  PLM: 

•  Capturing  customer  requirements  better, 

•  Creating  more  innovative  products, 

•  Delivering  the  required  product  on  schedule,  on  budget, 

•  Providing  superb  support  of  the  product  in  use, 

•  Preventing  future  failures  through  knowledge  of  past  failures, 

•  Schedule  maintenance  effectively  based  on  knowledge  of  the  actual  use  of 
the  product, 

•  Reducing  over-engineered  products  based  on  actual  use  of  products, 

•  Reducing  labor  costs  by  reducing  time  spent  on  data  retrieval  and 
management,  leaving  more  time  for  value-added  activities, 

•  Reducing  overhead  labor  by  reducing  paper  shuffling,  data  re-entry,  and 
data  formatting,  and 

•  Reducing  engineering  cost  by  reusing  designs.  (Softech  INC  and  John 
Stark  Associates,  2007) 


F.  CHAPTER  SUMMARY 

CIMdata  Corporation  stated:  “PLM  is  not  just  a  technology,  but  is  an  approach  in 
which  processes  are  as  important,  or  more  important,  than  data”  (Vasilash,  n.d.). 
According  to  CIMdata,  PLM  goes  beyond  data.  It  is  “a  business  approach  to  solving  the 
problem  of  managing  the  complete  set  of  product  definition  infonnation — creating  that 
information,  managing  it  through  its  life,  and  disseminating  and  using  it  throughout  the 
lifecycle  of  the  product.”  In  other  words,  in  order  to  effectively  make  decisions  from  the 
lifecycle  perspective,  the  data  must  be  properly  managed;  however,  managing  the  data 
properly  does  not  indicate  that  all  decisions  are  being  made  with  the  lifecycle  in  mind 
(Vasilash,  n.d.). 

Michael  Bauer,  the  executive  director  of  North  American  Automotive,  gave  an 
interview  in  which  he  stressed  that  collaborative  PLM  is  only  a  tool  designed  to  act  as  a 
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process  multiplier,  giving  benefits  to  those  with  good  processes  while  giving  those  with 
bad  processes  the  knowledge  to  catch  up.  He  said: 

Too  often  we  run  into  companies  that  are  trying  to  use  technology  for 
competitive  advantage,  but  it  is  really  the  process  that  makes  the 
difference.  If  you  have  best  practices  in  your  organization,  then  PLM  can 
help  amplify  the  results.  If  you  don’t  have  best  practices  in  your 
organization,  then  PLM — at  least  the  newly  developed  PLM  products  that 
encompass  the  learning  from  a  multitude  companies — can  help  you  get 
much  further  ahead  than  you  are.  (Vasilash,  n.d.) 

Collaborative  PLM  has  an  impact  on  all  the  functional  areas  of  a  company: 
design,  engineering,  manufacturing,  sales,  operation,  and  service.  Collaborative  PLM  is 
the  next  generation  of  LEAN  thinking,  in  that  it  actively  substitutes  infonnation  for 
wasted  time,  material,  and  energy.  This  information  helps  designers  reduce  the  time 
spent  designing  items  that  already  exist,  and  instead  it  allows  them  to  apply  time  to 
innovation  or  improvements  to  make  the  product  better.  People  can  spend  time 
researching  ways  to  improve  the  process,  and  increase  efficiency  and  productivity,  by 
figuring  out  ways  to  use  less  material  or  create  products  that  are  more  easily  produced. 

It  is  possible  to  design,  validate,  and  test  products  entirely  in  the  virtual  space. 
This  not  only  creates  better  products,  but  also  provides  confidence  that  the  products  will 
perform  at  the  level  expected  by  the  customer.  Products  that  can  exceed  the  expectation 
of  the  customer  are  the  real  definition  and  test  of  quality. 

The  investment  into  collaborative  PLM  is  not  insignificant.  For  the  Navy  to 
acquire  software,  hardware,  consulting,  education  and  training,  the  cost  could  easily 
surpass  several  hundred  million  dollars.  However,  the  collaborative  PLM  providers 
foresaw  this  financial  barrier,  and  the  architecture  they  created  helps  overcome  this 
hurdle.  Collaborative  PLM  can  be  phased  in  on  a  project-by-project  basis.  As  we  will  see 
later,  there  are  already  several  Navy  acquisition  programs  using  collaborative  PLM 
software.  Collaborative  PLM  is  a  conglomeration  of  services  that  build  upon  each  other, 
producing  benefits  greater  than  the  individual  contributions.  Another  element  of  the 
architecture  is  the  ability  to  unbundle  any  of  these  features,  either  to  stagger  the  capital 
investment  or  to  tailor  the  functionality  to  the  organization  or  project's  particular  needs. 
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With  as  much  as  80%  of  the  costs  set  early  in  design,  it  is  logical  that  the  majority 
of  the  benefits  of  collaborative  PLM  would  be  delivered  as  information  and  decision¬ 
making  would  be  improved  during  this  stage.  However,  one  of  the  biggest  benefits  is 
when  collaborative  PLM  initiatives  cross  functional  boundaries  and  maintain  the 
organization’s  focus  on  the  total  lifecycle.  The  author  hopes  that  this  chapter  has 
demonstrated  how  collaborative  PLM  can  help  an  organization  think  LEAN  and  decrease 
the  costs  of  wasted  time,  energy,  and  material.  However,  collaborative  PLM  is  not 
limited  to  only  a  cost-reduction  strategy,  for  it  can  also  lead  to  increasing  complexity, 
decreasing  cycle-times,  aiding  collaboration,  improving  innovation,  and  therefore  quality. 
In  essence,  it  can  ensure  that  the  product  is  under  control,  having  an  impact  on  all  aspects 
of  an  organization. 

Before  moving  on,  it  should  be  reiterated  that  the  benefits  outlined  in  this  chapter 
would  not  be  realized  simply  because  a  new  system  is  bought  and  installed.  A 
collaborative  PLM  suite  contains  some  very  useful  tools  to  assist  with  problems  in 
product  infonnation  and  lifecycle  management.  However,  a  technological  solution  rarely 
solves  any  problems  itself.  Collaborative  PLM  can  assist  with  the  organizational  changes 
that  are  needed  for  the  acquisition  community  to  gain  control  over  its  products.  The 
following  chapters  will  look  at  lessons  that  the  DoD  can  learn  from  successful 
organizations,  as  well  as  how  those  improvements  will  be  facilitated  by  the  capabilities  of 
a  collaborative  PLM  suite. 
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IV.  LEAN  PRODUCT  DESIGN 


We  can’t  solve  problems  by  using  the  same  kind  of  thinking  that  we  used 

when  we  created  them. 

—  Albert  Einstein 

The  preceding  chapter  introduced  collaborative  PLM  as  technology  designed  to 
provide  structure  and  efficiency  to  an  organization,  as  it  records,  retains,  and  organizes 
knowledge  throughout  the  lifecycle.  This  chapter  will  discuss  how  to  use  this  knowledge 
set  to  make  more  informed  decisions,  which  should  lead  to  correcting  the  inefficient, 
wasteful  processes  that  have  led  to  the  unsustainable  cost  growth,  schedule  delays,  and 
unacceptably  high  TOC  that  have  historically  plagued  the  DoD  acquisition  programs. 

A.  BACKGROUND 

The  essence  of  the  LEAN  philosophy  is  rather  simplistic:  It  is  the  pursuit  of  the 
perfect  product,  through  the  elimination  of  all  waste,  while  adding  value  as  defined  by  the 
needs  of  the  customer.  The  majority  of  the  research  and  applications  of  LEAN 
principles,  attempting  to  eliminate  waste  or  non  value-added  tasks,  has  focused  on 
production  and  manufacturing  processes,  overlooking  the  potential  benefits  during  the 
design  process  (Spear,  2004). 

There  are  differences  between  manufacturing  and  design  techniques,  which  means 
that  the  same  techniques  can’t  be  directly  applied  to  both  processes.  Manufacturing 
processes  are  usually  serial  and  visible,  making  it  easier  for  a  person  examining  the 
processes  to  identify  and  remove  waste.  However,  the  design  process  is  usually  not  serial, 
and  waste  is  much  harder  to  eliminate,  because  it  may  not  appear  until  much  later  in  the 
process.  For  instance,  if  two  different  systems  call  for  a  valve  to  be  installed  in  the  same 
physical  location,  the  mistake  might  go  unnoticed  until  construction,  when  the  problem 
becomes  visually  apparent. 

The  version  of  LEAN  product  design  presented  in  this  research  was  developed  by 
Bart  Huthwaite,  Sr.,  the  founder  of  the  Huthwaite  Innovation  Institute  and  the  thought 
leader  in  the  emerging  business  process  known  as  “Systematic  Corporate  Innovation.” 
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This  is  a  method  for  giving  managers  the  knowledge  to  make  corporate  innovation 
understandable,  repeatable,  and  very  importantly,  measurable.  Huthwaite  has  mentored 
managers  and  teams  in  corporate  innovation  worldwide  at  more  than  1000  companies 
over  the  past  30  years.  Huthwaite  used  the  following  analogy  to  get  to  the  heart  of  the 
issue:  “What  is  needed  is  more  fire  prevention  and  less  firefighting”  (Huthwaite,  n.d.  a, 
p.  1  ).  Huthwaite  described  that  just  as  firefighters  are  portrayed  as  heroes  on  the  front 
pages  of  newspapers,  organizations  have  their  own  heroes,  who  are  constantly  called 
upon  to  put  out  fires  and  save  the  company  or  project.  Underappreciated  is  the  fire 
inspector  who  saves  far  more  homes  by  ensuring  that  a  fire  never  breaks  out  in  the  first 
place  and  accomplishes  this  feat  for  a  fraction  of  what  it  cost  to  put  out  the  fire.  The  LPD 
is  the  fire  inspector  in  his  analogy.  Huthwaite's  philosophy  is  essentially  the  principle 
that  a  more  productive  way  to  eliminate  the  waste  in  the  process  is  to  ensure  that  it  will 
not  happen  in  the  first  place. 

B.  WHAT  IS  LEAN  PRODUCT  DESIGN? 

Huthwaite  would  answer  the  question  “What  is  Lean  Product  Design?”  by  saying 
“it  is  a  verb  and  a  noun.”  As  a  noun,  it  is  a  product  that  has  been  created  to  deliver  high 
value  with  low  waste.  As  a  verb,  it  describes  the  design  process  to  create  such  a  product 
(Huthwaite,  2007a).  The  method  presented  in  this  paper  goes  beyond  the  traditional 
approach  of  elimination  of  the  production  waste  on  the  factory  floor  by  extending  the 
efforts  to  the  eliminating  waste  experienced  by  the  supplier  and  customer  as  well. 
Another  reason  for  this  methods  section  is  the  comprehensive  approach  to  balancing  the 
need  for  waste  reduction  and  value  addition  across  the  entire  lifecycle.  This  particular 
application  of  LEAN  design  also  pairs  nicely  with  the  capabilities  of  a  collaborative  PLM 
suite,  and  its  goal  of  integrating  knowledge  across  all  domains  of  the  lifecycle. 

Huthwaite  evolved  the  following  LEAN  Design  Equation  while  working  with 
hundreds  of  design  teams  as  a  consultant  (Huthwaite,  2007a). 

Strategic  Ilities  -  Evil  lags  =  LEAN  Product  Success 
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Huthwaite  defines  the  strategic  “Ilities”  as  the  values  and  attributes  that  both  the 
producing  organization  as  well  as  the  ones  customers  seek  from  a  product  such  as 
“manufacturab-ility,”  “maintainab-ility,”  “durabil-ity,”  and  so  on.  The  evil  “Ings”  are  the 
processes  or  tasks  that  create  the  potential  for  quality  loss,  high  costs,  and  slow  time  to 
market.  The  term  describes  no-value  processes  such  as  “inspect-ing,”  “fix-ing,”  “repair¬ 
ing,”  and  other  non-productive  tasks  throughout  the  lifecycle  (Huthwaite,  2007b,  p.  139). 
The  LEAN  approach  helps  design  teams  find  a  design  solution  that  maintains  a  balance 
between  values  as  opposed  to  trying  to  maximize  one  at  the  expense  of  all  others.  For 
example,  the  LEAN  approach  would  prevent  the  design  of  the  most  technically  capable 
ship  ever  created  only  to  discover  all  that  technology  made  it  unaffordable.  Instead,  the 
LEAN  philosophy  finds  a  balance  between  all  the  customer  values;  using  this  big  picture 
approach  produces  an  optimal  solution. 

C.  “LAWS”  OF  LEAN  DESIGN 

The  following  section  will  discuss  four  of  the  five  factors  Bart  Huthwaite  calls  his 
“laws”  of  LEAN  design.  An  additional  law,  the  law  of  marketplace  pull,  would  be 
relevant  to  the  requirement  generation  process,  but  it  is  outside  the  scope  of  this  research 
and  as  a  result  was  eliminated.  Huthwaite  described  his  laws  as  “the  most  direct  route  to 
product  value  and  simplicity,  giving  you  the  ‘true  north’  of  what  LPD  is  all  about.  They 
will  guide  you  so  the  ‘how  to’  of  making  LEAN  design  will  really  work  for  you” 
(Huthwaite,  n.d.  b,  p.  43). 

1.  Law  of  Strategic  Value 

Projects  are  initiated  to  satisfy  particular  primary  values  of  customers,  and  are 
balanced  against  values  held  by  an  organization.  These  values  are  the  guiding  principles 
used  to  develop  the  requirements.  Understanding  the  customer  values  will  help  designers 
understand  the  “why”  that  is  driving  a  particular  requirement  and  will  lead  to  a  more 
complete  design. 

Actively  managing  the  product  across  all  four  of  the  lifecycle  domains  (design, 

supply,  manufacturing,  and  customer)  will  result  in  a  better  understanding  of  what  the 

product  needs  to  be.  To  help  design  teams,  Mr.  Huthwaite  has  developed  a  list  of 
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questions  that  help  designers  identify  stakeholders’  strategic  values  (Table  4).  He  stressed 
that  “good  designs  always  begin  with  problem  seeking  not  problem  solving”  (Huthwaite, 
2007a,  p.  64). 


Table  4.  Customer  and  Company  Primary  Values 

(After  Huthwaite,  2007a) 


Primary  Customer  Values 

Performability 

Will  the  product  perform  as  expected? 

Affordability 

What  will  it  cost? 

Featureability 

Will  it  provide  added  benefits? 

Deliverability 

When  will  it  be  ready? 

Useability 

Can  1  quickly  and  easily  install  it  and  learn  to  use  it? 

Maintainability 

How  easy  will  it  be  to  keep  in  service? 

Durability 

Can  it  withstand  abuse? 

Imageability 

Will  it  convey  an  image  of  quality  and  prestige? 

Primary  Company  Values 

Profitability 

Will  it  deliver  profit  at  an  acceptable  level? 

Investability 

Does  the  product  make  sense  in  terms  of  payback? 

Riskability 

Are  the  risks  we  must  take  prudent? 

Produceability 

Can  the  factory  and  supply  chain  deliver  this  product? 

Marketability 

Do  we  have  the  means  to  sell  this  product? 

Growability 

Does  this  product  offer  growth  and  market 
expansion? 

Leverageabilty 

Does  this  product  build  on  our  core  competencies? 

Respectability 

Will  this  product  strengthen  our  reputation? 

By  “problem  seeking”  and  exploring  each  of  the  values  found  in  Table  4  with  the 
stakeholders,  the  designers  will  understand  the  priorities  and  what  the  stakeholders  want 
from  the  product.  Each  of  these  value  categories  has  opportunities  for  the  program  to 
conduct  tradeoffs,  to  create  the  optimal  design  solution  for  the  particular  stakeholder.  For 
instance,  when  designing  the  Virginia  (SSN  774)  class  submarine,  the  Navy  valued 
affordability  above  all  other  attributes  except  stealth.  During  each  trade,  the  deciding 
factor  was  affordability  unless  it  dealt  with  stealth  (General  Dynamics  Electric  Boat, 
2002).  Thus,  without  understanding  what  the  customer  values,  the  design  team  will  be 
unable  to  deliver  an  optimal  solution. 
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2. 


Law  of  Waste  Prevention 


In  Huthwaite’s  model  of  LEAN  Product  Development,  every  decision  made 
should  be  to  either  enhance  one  of  the  values  discussed  in  the  previous  section  or  to 
minimize  the  potential  for  waste.  The  seven  types  of  waste  identified  in  Table  5  are 
responsible  for  the  majority  of  waste  found  in  programs  (Huthwaite,  2007a).  A  general 
rule  is  the  sooner  waste  is  identified,  the  cheaper  it  will  be  to  resolve.  Once  the  concept 
becomes  a  prototype,  or  takes  root  in  the  mind  of  your  team  members,  the  flexibility  and 
receptivity  to  change  shrinks  drastically  (Huthwaite,  2007b). 


Table  5.  Product  Life  Cycle  Waste 

(After  Huthwaite,  2007a) 


Seven  Worst  Solutions 

Name 

Description 

Complex 

Many  different  processes,  high  quality  required  to  deliver  product's 
value  both  on  factory  floor  and  in  customer  use.  Each  process  or  step 
takes  time,  costs  money,  and,  if  performed  wrong,  can  result  in  a 
quality  flaw  that  must  be  corrected. 

Precise 

Solution  requiring  precision  at  the  outer  limits  of  manufacturer's 
ability  to  produce  the  product  or  the  customer's  ability  to  use  it. 

Variable 

Processes  that  are  not  "mistake  proof"  or  are  applied  inconsistently. 

Sensitive 

Products  that  are  easily  flawed,  not  robust. 

Immature 

Solutions  not  previously  validated  for  specific  application.  Difficult  to 
accurately  predict  cost,  schedule,  and  testing  needed  for 
development. 

Dangerous 

Solutions  with  dangerous  impact  on  humans  or  environment. 

Skill  Intensive 

Solutions  requiring  high  degree  of  training  or  experience. 

3.  Law  of  Innovation  Flow 

“There  is  always  a  way  to  do  it  better  .  .  .  find  it!”  — Thomas  Edison 

According  to  Huthwaite  (2007a),  The  Law  of  Innovation  Flow  states,  “we  must 
provide  the  means  for  all  members  of  the  design  team  to  contribute  to  the  innovation 
process.  Only  by  seeing  the  design  challenge  from  many  different  perspectives  will  we 
ever  be  able  to  solve  it”  (p.  87). 
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Developing  a  good  design  requires  systematically  working  through  the  design 
space,  exploring  all  possibilities  prior  to  selecting  a  particular  solution.  In  The  Lean 
Design  Solution,  Huthwaite  recommends  that  design  teams  should  work  the  problem 
from  the  system,  through  the  subsystems,  down  to  the  parts  levels,  looking  to  capitalize 
on  the  five  targets  of  opportunity:  functions,  parts,  processes,  materials,  and  people 
(Huthwaite,  2007a,  p.  99).  Ship  designers  have  an  endless  set  of  opportunities  to  improve 
the  design.  When  looking  at  functions,  the  idea  for  interchangeable  mission  modules  on 
LCS  was  created.  By  analyzing  unique  part  counts,  a  common  parts  catalog  was 
identified  as  a  way  to  reduce  the  strain  on  the  logistics  system.  Through  examining 
processes,  the  question  was  raised  of  why  ships  cannot  be  built  upside  down  to  make  it 
easier  on  the  welders.  Scrutinizing  the  use  of  materials  led  to  aluminum  superstructures, 
replacing  steel,  saving  weight  and  painting  costs.  Focusing  on  reducing  personnel  cost 
and  improving  safety  led  to  the  idea  that  watch  standers  could  be  removed  as  systems 
were  automated  and  capable  of  being  controlled  remotely.  The  first  design  is  never  the 
best,  and  the  second  and  third  are  only  a  step  in  the  journey  to  success  (Huthwaite,  2007a, 
p.  99). 

Collaborative  PLM  applications  offer  the  designer  a  powerful  tool,  the  ability  to 
store  and  organize  data  so  no  idea  has  to  be  thrown  away.  Every  attempt  to  solve  a 
particular  problem  has  merit,  a  good  idea  could  be  iterated  to  become  great,  a  failure 
today  could  be  tomorrow’s  answer,  a  dead  end  may  serve  as  a  warning  not  to  repeat  the 
same  mistakes  (Huthwaite,  2007b). 

4.  Law  of  Fast  Feedback 

Metrics  provide  a  sense  of  direction  to  a  program.  That  direction,  be  it  right  or 
wrong,  depends  on  the  quality  of  the  metric.  DoD  programs  rely  on  eamed-value  metrics 
and  status  reports  to  measure  a  program’s  health.  Earned  Value  Management  (EVM)  is  a 
method  for  integrating  the  scope,  schedule,  and  resources  for  measuring  project 
performance.  It  compares  the  amount  of  work  or  effort  that  was  planned  with  what  was 
actually  earned  and  spent  to  determine  if  cost  and  schedule  perfonnance  were  as  planned. 
A  limitation  of  these  metrics  is  that  they  only  indicate  when  a  problem  already  exists. 
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During  the  2010  NPS  Defense  Acquisition  Symposium,  an  analogy  compared  the 
limitation  of  these  metrics  to  driving  your  car  by  only  looking  at  the  rear-view  mirror. 
No  matter  how  successful  metrics  and  testing  are  at  uncovering  waste,  a  better  strategy  is 
to  look  out  the  windshield  and  ensure  that  waste  was  never  there  to  begin  with.  Being 
over  budget  or  behind  schedule  is  only  a  symptom  of  a  problem.  To  address  the  root 
cause,  additional  research  must  be  conducted.  Because  earned  value  is  not  a  real-time 
metric,  by  the  time  the  issue  is  actually  resolved,  a  program  may  have  been  traveling  in 
the  wrong  direction  for  some  time. 

Earned-value  measurements  are  still  valuable  and  need  to  be  maintained.  They 
fall  into  a  category  of  metrics  called  “performance  metrics”  (M.  Brown,  2006).  A 
performance  metric  lets  you  know  if  you  are  tracking  toward  your  goal  and  if  corrective 
action  is  needed.  A  second  category  called  “predictive  metrics”  is  potentially  more 
valuable  to  managers  (M.  Brown,  2006).  These  metrics  will  tell  us  the  likelihood  that  our 
decisions  will  have  the  desired  results.  Huthwaite  (2007a)  recommended  using  predictive 
metrics  to  achieve  three  important  benefits: 

1.  By  providing  focus  and  direction,  they  help  ensure  all  stakeholders’  visions 
for  product  goals  are  aligned. 

2.  They  provide  a  better  understanding  of  the  cause-and-effect  relationship 
between  design  actions  and  results,  providing  decision-makers  the  knowledge 
needed  to  make  good  decisions. 

3.  Once  you  have  buy  in  on  the  vision,  implementation  becomes  easier. 
Predictive  metrics  are  developed  looking  towards  the  end  state,  (p.106  ) 

Over  his  years  of  consulting  experience,  Huthwaite  identified  seven  rules  quoted 
as  follows,  which  he  contended  would  make  for  effective  measurement  and  feedback 
(Huthwaite,  2007a,  pp.  107-1 1 1). 

“Rule  one:  Measure  what  is  most  important  to  your  customers,  not  just  what  is 
easiest  to  measure.”  A  project  may  be  on  schedule,  under  budget,  and  meet  all  of  the 
technical-perfonnance  metrics,  but  if  it  fails  to  deliver  on  the  customer  values,  it  cannot 
be  considered  a  success.  Finding  an  accurate  metric  to  forecast  designs  TOC  is  very 


43 


difficult,  but  if  designs  cannot  be  evaluated  based  on  this  metric  operation  and 
sustainment,  costs  might  eventually  exceed  the  budget. 

“Rule  two:  Be  cautious  with  metrics,  as  the  wrong  metric  can  lead  to  the  wrong 
conclusion.”  For  instance,  DoD  program  managers  have  measured  and  been  held 
accountable  for  the  acquisition  cost  of  their  programs.  Is  it  wise  to  trade  one  dollar  of 
savings  during  acquisition  for  ten  dollars  during  sustainment?  Acquisition  costs  could  be 
the  wrong  metric  for  determining  program  success. 

“Rule  three:  Use  both  hard  and  soft  metrics.”  In  his  book,  Keeping  Score:  Using 
the  Right  Metrics  to  Drive  World  Class  Performance,  Mark  Brown  emphasized  the 
importance  of  soft  metrics:  “Soft  measures  are  measures  of  customer  opinions, 
perceptions  and  feelings.  These  are  leading  edge  indicators  that  should  be  used  to  try  and 
predict  customer  behavior.  The  opinions  and  feelings  of  customers  are  extremely 
important”  (M.  Brown,  2006,  p.  116).  For  instance,  measuring  how  many  targets  a  new 
radar  can  track  and  engage  simultaneously  is  an  important  metric  and  should  be  recorded. 
The  human  operator  must  also  be  able  to  interact  with  the  new  radar,  and  the  evaluation 
must  ask:  “Has  the  operator's  satisfaction  been  measured?”  Virtual  reality  tools  such  as 
computer  automated  virtual  environment  (CAVE)  have  been  designed  to  allow  sailors  to 
walk  around  inside  and  interact  with  a  design  years  before  it  becomes  a  reality  (Briggs  et 
ah,  2009).  As  those  tools  are  integrated  into  the  collaborative  PLM  suite,  the  feeling  and 
observations  concerning  the  design  can  be  embedded  in  the  model,  giving  designers 
another  fonn  of  feedback.  However  important  soft  metrics  are,  they  should  be 
supplemented  by  hard  measures  of  customer  satisfaction  to  track  what  the  customer 
actually  does. 

“Rule  four:  Measure  for  direction  first  and  precision  later.”  During  the  very  early 
stages  of  design — for  instance,  when  the  design  team  is  looking  at  concepts  for  hull 
design — there  are  no  hydrostatic  details  to  be  measured  with  any  degree  of  accuracy.  To 
compensate  for  the  lack  of  specifics,  consensus  measurements  such  as  Delphi  can  capture 
experts’  gut  feelings,  and  this  type  of  measurement  will  let  designers  know  if  they  are  on 
the  right  track.  Precision  can  be  worked  out  later,  once  a  project  is  heading  in  the  right 
direction. 
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“Rule  five:  Get  information  concurrently  on  the  “ilities,”  or  the  values  and 
attributes  that  both  the  producing  organization  as  well  as  the  customer  seek  from  a 
product,  and  the  “ings,”  or  processes  or  tasks  that  create  the  potential  for  quality  loss,  and 
high  costs.”  Many  DoD  programs  focus  on  one  area  at  a  time,  and  lose  sight  of  the  total 
picture.  Section  D  will  show  how  radar  charts  can  be  used  to  capture  the  entire  design 
solution. 

“Rule  six:  Make  sure  everyone  is  on  the  same  feedback  system.”  The 
measurement  creation  process  helps  form  consensus  on  what  problems  must  be  solved 
and  how  they  will  be  evaluated.  It  is  hard  to  win,  if  everyone  is  playing  by  different 
rules. 

Finally,  “rule  seven:  Enable  those  who  will  be  measured  to  have  input  into  the 
creation  of  the  measurement  system.”  Ownership  is  a  powerful  way  to  assure  a  feedback 
system  will  be  used. 

Collaborative  PLM  has  capabilities  that  compliment  each  of  these  seven  rules  and 
can  assist  in  the  development  of  an  appropriate  set  of  metrics.  As  the  design  is 
progressing,  collaborative  PLM  can  store  various  data  points.  After  enough  data  is 
captured,  statistical  analysis  can  reveal  which  of  the  captured  data  points  correlate  to  the 
factor  that  dictates  success  or  failure.  For  example,  a  collaborative  PLM  analysis  might 
show  schedule  delays  are  related  to  design  stability,  which  can  be  measured,  by  the 
number  of  change  orders,  and  the  number  of  change  orders  is  correlated  to  the  percentage 
of  drawings  complete  by  a  particular  milestone. 

D.  LEAN  DESIGN  SCORECARDS 

Measure  the  right  things  and  get  the  right  results.  Measure  the  wrong 

things  and  get  the  wrong  results.  — Proverb  (Huthwaite,  2007a) 

Several  previous  sections  have  discussed  the  value  of  metrics  and  called  for  the 
development  of  more  predictive  metrics  to  ensure  that  programs  are  heading  in  the  right 
direction.  This  section  is  going  to  describe  one  process  that  can  help  create  these 
predictive  metrics. 
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According  to  Product  Development  for  the  LEAN  Enterprise,  some  of  Toyota’s 
success  was  attributed  to  its  knowledge-based  product  design.  This  approach  encourages 
sharing  and  applying  collective  knowledge  to  improve  the  probability  of  product 
development  success  (Kennedy,  2003).  The  following  method  is  a  technique  to  capture 
knowledge  and  assess  the  leanness  of  the  total  design  solution.  This  example  comes  from 
Bart  Huthwaite’s  book  The  Lean  Design  Solution,  in  which  he  stresses  that  the  greatest 
value  comes  from  working  with  the  stakeholders  to  develop  the  criteria  for  how  the 
program  will  be  evaluated,  where  the  byproduct  of  that  process  is  referred  to  as  the 
scorecard.  This  process  is  valuable,  as  it  forces  communication  between  stakeholders, 
gives  the  design  team  insight  into  stakeholder  priorities  and  encourages  the  exploration  of 
many  different  solutions  across  the  entire  lifecycle  (Huthwaite,  2007a). 

The  best  way  to  develop  project  scorecards  is  through  a  dialogue  between  the 
stakeholders  and  the  design  team.  The  process  begins  by  asking  the  stakeholder  to 
develop  criteria  for  the  rating  scale  (Table  6),  making  sure  to  capture  the  rationale  by 
asking  “why.” 


Table  6.  Example  of  Scorecard  Rating  Scale 

(After  Huthwaite,  2007a) 


Rating 

Value  Level 

Description 

9-10 

Extremely  High  Value 

Sets  the  standard  for  the  industry. 

7-8 

High  Value 

Superior  to  most  competitors. 

5-6 

Acceptable 

Meets  expectations  most  of  the  time. 

3-4 

Low  value 

Frequently  does  not  meet  expectations. 

1-2 

Extremely  Low  Value 

Well  below  competition. 

Once  consensus  between  the  design  team  and  key  stakeholders  is  reached 
concerning  scale,  the  baseline  is  scored  along  with  any  alternatives  that  need  to  be 
compared  (Figure  10).  Once  again,  it  is  important  to  capture  the  “why”  behind  each 
rating;  this  will  give  true  insight  to  the  values  behind  the  decisions.  For  instance,  when 
evaluating  two  designs  based  on  maximum  speed,  a  faster  ship  will  be  more  desirable 
because  it  offers  operational  flexibility.  However,  knowing  how  much  speed  is  enough  is 
important  for  the  designers,  as  a  ship  may  be  able  to  go  30  knots  on  4  engines,  but  to 
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reach  35  knots  it  would  need  6.  Those  additional  5  knots  have  a  cost  associated  with 
them:  either  it  could  be  money  for  the  additional  engines,  or  it  could  be  removing  2 
missiles  to  decrease  the  weight.  Understanding  the  values  attributed  by  the  stakeholders 
will  be  important  for  the  design  team  to  deliver  an  optimized  solution.  These  scorecards 
must  be  created  for  each  phase  of  the  lifecycle  to  fully  understand  the  impact  of  the 
design.  Recall  the  car  design  built  to  optimize  manufacturing  with  dire  repercussions  to 
maintenance:  Complexity  in  manufacturing  may  result  in  simplicity  for  the  user.  Unless 
both  of  these  environments  are  explored,  it  is  impossible  to  make  informed  tradeoffs. 
Scorecards  can  also  be  applied  at  all  levels  of  the  design  from  the  component,  to  sub¬ 
system,  to  system,  to  system  of  systems.  This  technique  is  an  effective  way  to  share 
high-level  information  and  knowledge  among  those  involved  in  the  process,  ensuring 
alignment  to  the  strategic  goals  and  facilitating  quick  management  reviews. 
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Figure  10.  Examples  of  Value  and  Waste  Scorecards 

(After  Huthwaite,  2007a) 

E.  ACHIEVING  LEAN  DESIGN  WITH  COLLABORATIVE  PLM 

Collaborative  PLM  was  created  to  manage  a  product  and  its  associated  data 

throughout  the  lifecycle,  from  the  cradle  to  the  grave.  So  to  speak,  LEAN  is  a  strategy  to 

remove  waste  throughout  processes,  saving  the  resources  expended  on  wasteful  activities, 

in  order  to  ideally  use  them  more  profitably.  The  data  collected  and  organized  inside  the 

collaborative  PLM  environment  will  be  used  to  accomplish  the  LEAN  analysis  to  identify 

wasteful  processes.  Studies  have  documented  cases  in  which  applying  LEAN  principles 

to  product  development  has  reduced  product  development  cycle-times  by  60-70%  (Fiore, 

2004).  Once  the  more  efficient  process  is  identified,  collaborative  PLM  has  the 
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capability  to  automate  the  workflow  and  institutionalize  the  efficient  process,  making 
both  data  and  processes  accessible  to  users  throughout  the  lifecycle  to  eliminate 
repetition,  redundancy,  errors,  and  other  forms  of  waste. 

Peter  Schmitt,  vice  president  of  marketing  communications  for  Dassault  System 
in  the  Americas,  explained: 

If  you  drive  the  concepts  and  principles  of  LEAN  up  the  chain  of  product 
development,  you're  coming  to  manufacturing  planning,  and  from  there  to 
the  product  design.  The  further  up  the  product  lifecycle,  the  bigger  the 
benefits  you  get.  It's  that  old  saw:  A  mistake  detected  in  design  costs  $  1 ; 
in  manufacturing  planning,  $100;  in  production,  $1,000.  (Gould,  n.d., 
para.  4) 

To  show  how  collaborative  PLM  can  facilitate  LEAN,  I  will  dissect  the  following 
explanation  by  David  Van  Horn,  director  of  Archstone  Consulting: 

LEAN  is  all  about  designing  and  developing  products  that  meet  or  exceed 
customer  needs,  that  can  be  effectively  and  efficiently  produced  and 
serviced,  and  that  do  not  involve  excessive  development  investment.  .  .  . 

LEAN  “works  on”  physical  product  and  information  flow,  while  LPD 
“works  on”  engineering  product  and  information  flow-virtual  products,  if 
you  will.  (Dassault  Systems,  2007,  p.  2) 

Van  Horn  states  that  products  must  meet  or  exceed  customer  needs.  Collaborative 
PLM  cannot  detennine  a  customer’s  needs  or  wants,  but  it  can  store  the  infonnation 
about  market  needs  and  wants  so  that  those  qualified  to  separate  the  good  ideas  from  the 
bad  can  access  it.  Howie  Distel,  a  solution  architect  for  Dassault  Systems,  explained,  “In 
defining  a  product  that  has  category  killer  potential,  it  is  important  to  eliminate  bad 
concepts  quickly.  The  ability  to  create  rapid  design  candidates  and  interrogate  those 
designs  through  simulation  and  validation  of  virtual  product  data  is  at  the  heart  of  PLM” 
(Dassault  Systems,  2007,  p.  2). 

Van  Horn  also  referred  to  how  designing  products  with  manufacturability  and 
maintainability  requires  interactions  between  the  manufacturing  and  maintenance 
departments  early  in  the  design.  He  argued  that  early  in  the  design  process,  making  an 
informed  decision  is  key  to  program  success  by  citing  that  “70-80%  of  the  final  unit  cost 
of  a  product  is  driven  by  research-  and  development-based  decisions,  often  without 
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conscious  awareness  of  the  repercussions  of  those  decisions”  (Jaruzelski,  Dehoff,  & 
Bordia,  n.d.).  If  a  problem  does  not  emerge  until  after  the  design  is  complete  and  the 
product  is  in  production  or  operation  and  sustainment,  there  may  not  be  enough  time  or 
resources  to  go  back  and  fix  it.  Collaborative  PLM  helps  produce  fast  feedback,  by 
integrating  all  parties  involved,  and  allowing  each  member’s  specialized  expertise  to  be 
incorporated.  Helping  bring  those  unconscious  decisions  to  light  and  manage  them  with 
processes  designed  to  eliminate  waste  is  a  key  capability  of  collaborative  PLM. 

Excess  development  investment  should  be  minimized  by  collaborative  PLM, 
enabling  broad  visibility  into  the  product  data  and  keeping  everyone  infonned  on 
progress,  regardless  of  their  role  or  location.  Allowing  everyone  to  access,  create, 
modify,  and  manage  information  concurrently  from  a  single  source  eliminates  the 
traditional  data  silos  that  lead  to  errors  from  working  with  outdated  data.  Powerful 
search  capability  makes  it  easier  to  find  existing  designs  that  meet  or  could  be  adapted  to 
fit  the  current  project  needs,  eliminating  rework  and  reinvention.  Employing  the  use  of 
relational  design  templates  enables  a  part  to  be  designed  once  and  automatically  adjusted 
to  fit  new  parameters  when  required.  Using  templates  to  standardize  processes  will  help 
create  the  consistency  that  will  improve  the  manufacturability  of  the  product.  These 
examples  demonstrate  how  the  structure  and  workflow  can  be  built  inside  collaborative 
PLM,  reducing  resources  spent  on  wasteful  activities. 

Collaborative  PLM  operates  with  a  knowledge-based  engineering  method  that  can 
be  used  to  capture  corporate  know-how  and  standards  and  can  improve  quality  and 
consistency  across  the  portfolio  of  programs.  As  Distel  stated,  “Over  time,  collaborative 
PLM  properly  used  will  become  a  repository  for  everything  the  company  knows  and 
what  they  have  learned  from  past  projects.  Because  you  have  so  much  time  on  the  back 
end,  collaborative  PLM  makes  it  possible  to  spend  more  time  in  the  early  stages  of 
development,  investigating  design  alternatives  that  lead  to  new  innovations”  (Dassault 
Systems,  2007,  p.  3). 

Products  can  be  mocked  up  in  a  virtual  3D  environment  to  determine  if  project 

goals  will  be  met.  This  can  usually  be  done  for  lower  cost  and  in  less  time  than  building 

a  physical  model.  These  savings  can  be  applied  to  compare  several  different  alternative 
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designs  to  detennine  the  clear  winner.  Boeing,  for  example,  rolled  out  the  virtual  design 
of  its  new  787  Dreamliner  in  2006.  This  presentation  included  a  3D  model,  virtual 
simulations,  video  of  production  start  up,  and  the  final  assembly  production  flow.  Being 
able  to  correct  deficiencies  in  the  process  while  in  the  virtual  environment  led  to 
efficiencies  that  allowed  the  actual  first-time  assemblies  to  be  constructed  in  hours,  not 
the  days  originally  scheduled.  Those  same  efficiencies  resulted  in  calculations  that  show 
that  an  overall  operating  cost  has  been  improved  an  additional  20%  from  the  original 
projections  (Gates,  2006). 

These  are  just  a  few  examples  of  how  collaborative  PLM  can  facilitate  the 
application  of  LEAN  best  practices  during  the  product-development  cycle.  By 
eliminating  routine  work,  streamlining  processes,  exploring  alternatives,  supporting 
concurrent  design,  eliminating  data  inconsistencies,  and  improving  communication 
between  team  members,  collaborative  PLM  can  lead  to  an  LPD  process  in  which  results 
surpass  those  experienced  in  the  manufacturing  sector. 
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V.  FRAMEWORK  BEHIND  DEVELOPMENT  OF  FUTURE 

STATE 

A.  FOUNDATIONS  OF  SUCCESSFUL  ORGANIZATIONS 

This  chapter  discusses  how  the  synergy  between  organizations,  people, 
information,  technology,  processes  and  practices  can  create  a  successful  organization. 
This  grouping  will  also  be  the  structure  behind  how  the  recommendations  are  presented 
in  the  following  chapters. 

When  first  being  introduced  to  collaborative  PLM,  it  is  easy  to  think  of  it  only  as 
a  new  software  technology,  allowing  tasks  previously  impossible  or  at  least  improbable, 
to  be  accomplished.  Assuming  that  improvements  to  our  organization  are  only  possible 
when  a  new  technology  delivers  some  missing  capability  makes  the  assumption  that 
everything  about  our  people,  organizations,  and  processes  was  perfect  and  that  the  lack  of 
capability  delivered  by  the  new  technology  was  the  root  cause  behind  the  particular 
problem.  Collaborative  PLM  as  a  software  suite  could  be  considered  a  new  technology, 
it  can  deliver  capabilities  that  our  programs  currently  do  not  have,  but  implementing  a 
collaborative  PLM  suite  is  only  the  first  step  toward  organizing  and  improving  the 
information  available,  enabling  people  and  organizations  to  perform  their  practice  and 
processes  most  efficiently. 

In  his  book  Product  Lifecycle  Management  Driving  the  Next  Generation  of  LEAN 
Thinking,  Michael  Grieves  described  the  relationship  between  technology,  process,  and 
people.  The  book  has  a  good  discussion  of  the  three  main  areas  of  an  organization  that 
must  work  together  in  order  to  be  successful.  Figure  11  demonstrates  how  Grieves 
visually  captured  the  interaction  between  technology  and  processes  in  effecting  outcomes 
(Grieves,  2006).  The  first  quadrant  combines  low  technology  and  poor  processes.  This 
usually  produces  undesirable  outcomes  because  of  the  tremendous  waste  of  time, 
material,  and  energy.  In  this  quadrant,  even  routine  tasks  are  not  standardized.  There  is  a 
lot  of  trial  and  error,  as  people  are  trying  to  figure  out  how  to  accomplish  tasks,  and  little 
or  no  infonnation  is  learned,  resulting  in  rework  and  other  non-value  added  activities. 
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Figure  11.  Interactions  Between  Process  and  Technology 

(From  Grieves,  2006) 

Improving  the  technology  without  addressing  the  process  will  move  an 
organization  into  the  second  quadrant.  The  high  technology  and  poor  process  quadrant 
produces  outcomes  that  may  be  more  consistent,  but  not  necessarily  favorable  for  the 
organization.  An  example  would  be  if  a  new  technology  such  as  collaborative  PLM 
automated  an  organization’s  processes,  without  addressing  the  poor  processes.  In  this 
scenario,  the  control  over  the  process  offered  by  collaborative  PLM  actually  becomes  a 
burden  to  employees,  because  they  are  forced  to  comply  with  the  poor  process.  This  will 
result  in  employees  finding  ways  to  work  around  the  system  or  simply  putting  the  least 
amount  of  effort  possible  to  move  through  the  bad  process.  Both  results  eliminate  most  of 
the  benefits  discussed  in  the  previous  chapters.  This  behavior  negatively  impacts  the 
return  on  investment  for  the  system.  Lack  of  understanding  as  to  why  outcomes  are  not 
improved  is  usually  the  justification  for  the  next  new  technology  that  shows  promise. 

The  third  quadrant  of  Figure  1 1  represents  low  technology  but  good  processes.  An 
actual  example  of  this  quadrant  would  be  Toyota  and  their  total  production  system  (TPS). 
Toyota  spends  a  lot  of  effort  training  its  employees  on  how  to  analyze,  improve,  and 
document  its  processes.  They  utilize  low  tech  solutions  such  as  Kanban  cards.  While 
Kanban  cards  are  common  in  manufacturing  processes,  they  are  in  effect,  the  message 
that  signals  depletion  of  product,  parts  or  inventory  that  when  received  will  trigger  the 
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replenishment  of  that  product,  part,  or  inventory.  Toyota  has  also  been  successful  in 
using  them  in  the  design  realm,  shaving  years  off  their  design  and  engineering  cycle 
(Spear,  2004). 

The  final  quadrant  in  the  figure  is  the  goal  of  each  organization:  high  technology 
and  good  processes.  In  this  quadrant,  the  technology  is  organized  and  structured  to 
enable  the  people  to  accomplish  tasks  more  efficiently  and  more  reliably  than  they  could 
otherwise.  There  is  structure  that  not  only  ensures  processes  and  practices  are  followed, 
but  that  they  are  continuously  analyzed  and  improved  to  capture  the  knowledge  needed  to 
prevent  repeated  mistakes.  In  this  quadrant,  the  processes  and  practices  are  so  well 
understood  that  they  can  be  simulated  in  the  virtual  space,  saving  time,  material,  and 
energy  (Grieves,  2006).  This  is  the  quadrant  where  collaborative  PLM  can  deliver  the 
benefits  needed  to  address  the  DoD  acquisition  portfolio’s  woes. 

Absent  from  the  four  quadrants  discussed  above  was  the  role  of  people.  All  the 
interactions  between  process  and  technology  are  dependent  on  the  people  in  the 
organization.  When  people  operate  with  good  intentions  and  are  motivated  and 
competent,  they  can  figure  out  a  way  to  improvise  and  will  make  even  poor  processes  and 
low  technology  work  for  them.  However,  if  people  set  out  with  willful  malice,  they  will 
use  the  same  ingenuity  and  find  ways  to  ensure  that  even  the  best  processes  fail.  Before 
presenting  the  case  studies,  lessons  learned,  and  recommendation  for  the  DoD 
shipbuilding-acquisition  portfolio,  it  will  be  helpful  to  explore  the  impact  of 
characteristics  of  practice,  processes,  organizations,  people,  information,  and  technology 
more  thoroughly. 

1.  Practices  and  Processes 

A  ship  design  program  manager  should  understand  the  differentiation  between  a 
process  and  practice  in  order  to  understand  what  and  how  adjustments  need  to  be  made 
and  to  know  what  a  software  vendor  is  promising  with  new  technologies.  Michael 
Grieves  explained  this  differentiation  in  his  book,  Project  Lifecycle  Management. 
Grieves  pointed  out  that  when,  “thinking  of  organizations  in  a  systems  view,  everything 
starts  with  given  inputs.  Processes  then  transform  those  inputs  into  a  well-specified, 
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predictable,  consistent  set  of  outputs”  (Grieves,  2006).  However,  when  looking  at  the 
Navy  portfolio,  while  you  can  argue  that  lately  outputs  have  been  consistent  and 
predictable,  it  would  be  hard  to  argue  that  those  outputs  are  the  desired  results.  Perhaps 
more  attention  needs  to  be  paid  to  the  so-called  processes  that  transform  the  resources. 

When  looking  across  the  spectrum  of  ways  to  accomplish  this  transfonnation, 
there  are  multiple  approaches  to  reaching  the  organizational  objectives.  Collaborative 
PLM  groups  these  approaches  into  three  categories:  “process,”  “practice”  or  “art” 
(Grieves,  2006).  The  most  defined  approach  is  a  process;  for  example,  a  machine  that 
takes  a  set  quantity  of  material  and  runs  at  a  set  speed  for  a  detennined  duration, 
producing  a  consistent  output.  On  the  other  end  of  the  spectrum  is  the  least  defined 
approach:  art.  Art  begins  with  unclear  inputs  that  are  transformed  through  unorthodox 
applications  fully  understood  only  by  the  artist.  Art  has  the  ability  to  produce  a  variety  of 
outputs,  to  be  selected  based  on  how  well  they  match  requirements.  The  results  are 
subjective,  and  consensus  may  never  be  reached:  for  example,  when  deciding  “What  is 
the  best  hull  shape  for  a  new  class  of  warship?”  In  between  the  art  and  process  is 
practice.  In  practice,  inputs  and  outputs  are  fairly  well  defined,  but  how  they  are 
transformed  is  not.  Practices  rely  on  judgment  and  experience  and  often  do  not  occur  in 
the  controlled  enviromnent,  for  instance,  determining  how  to  minimize  the  number  of 
change  orders  to  control  the  cost  escalation  of  a  program  (Grieves,  2006). 

Pointing  out  the  differences  between  these  concepts  is  important  for  a  few 
reasons.  First,  it  could  provide  an  explanation  as  to  why  our  programs  struggle  with 
inconsistent  perfonnance.  If  the  organization  is  executing  processes,  like  the  machine 
described  previously,  it  is  rational  to  eliminate  unnecessary  information  and  extra 
communications  in  order  to  LEAN  the  process.  However,  if  the  organization  is  in  fact 
using  practices,  this  approach  could  eliminate  necessary  information  needed  by  the 
decision  makers  to  make  an  informed  decision.  Second,  the  differences  are  important  in 
order  to  understand  what  a  vendor  is  offering.  Before  making  the  substantial  investment 
in  collaborative  PLM,  it  would  be  necessary  to  be  sure  it  is  structured  in  a  manner  to 
enable  operations  with  practices  as  well  as  processes.  For  instance,  a  process  is  very 
structured  and  the  goal  is  to  move  through  the  steps  as  efficiently  as  possible.  Practices 
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lack  the  same  structure  as  processes  so  the  goal  is  to  collect  enough  data  and  information 
during  each  step  to  assist  decision-makers  to  identify  the  patterns  (Grieves,  2006).  For 
collaborative  PLM  to  be  helpful,  it  must  have  the  ability  to  operate  organization 
activities,  whether  practices  or  processes.  Collaborative  PLM  should  help  an 
organization  categorize  its  tasks  and  evolve  practices  into  processes  wherever  possible. 
Processes  lend  themselves  to  automation,  thus  freeing  resources  to  concentrate  on 
practices  where  perception  and  judgment  are  important. 

2.  Organizations  and  People 

As  mentioned  above,  the  characteristics  of  the  people  will  have  a  dramatic 
influence  on  the  success  of  an  organization.  The  capabilities  of  people  within  any 
organization  are  varied.  Some  of  those  characteristics  contributing  to  an  employee’s 
capability  can  be  enhanced  and  will  be  discussed  below.  They  are  experience,  education, 
training,  and  support  (Grieves,  2006). 

a.  Experience 

One  definition  of  experience  is  active  involvement  in  an  activity  or 
exposure  to  events  or  people  over  a  period  of  time,  which  leads  to  an  increase  in 
knowledge  or  skill — basically,  to  keep  the  same  theme  in  this  paper,  knowing  how  to  use 
information  to  reduce  wasted  time,  material,  and  energy.  Experience  helps  reduce  the 
search  time  to  find  the  infonnation  needed  to  predict  the  outcomes  of  situations  with  a 
higher  probability  of  success. 

A  problem  with  experience  is  that  it  is  predominantly  an  individual 
characteristic,  meaning  when  you  lose  the  employee,  you  lose  the  experience.  The 
experience  of  the  DoD’s  workforce  is  one  of  the  issues  that  will  cause  problems  if  not 
addressed.  Due  to  the  downsizing  and  hiring  freezes  of  the  1990s,  a  significant  amount 
of  the  workforce  is  eligible  to  retire,  and  there  is  a  gap  between  them  and  the  large 
number  of  new  hires  waiting  to  take  over.  This  leaves  a  small  window  in  which  to 
transfer  the  requisite  knowledge  to  those  new  workers.  We  will  explore  specific 
recommendations  later,  but  collaborative  PLM  can  help  in  at  least  two  general  ways: 
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First,  it  can  embed  the  infonnation  into  the  processes,  and  second,  it  can  allow  new 
operators  to  gain  experience  in  the  virtual  world. 

b.  Education  and  Training 

Real-world  situations  that  present  opportunities  for  employees  to  gain 
necessary  experience  cannot  be  scheduled.  Unlike  the  real  world,  the  virtual  world  can  be 
used  to  simulate  any  situation,  rather  than  waiting  for  the  desired  opportunity  to  present 
itself,  and  the  virtual  world  to  be  scheduled.  This  simulation  is  a  method  of  education 
and  training.  Education  teaches  people  why  things  are  done,  while  training  focuses  on 
what  to  do.  Recall  from  earlier  the  differences  between  processes  and  practices. 
Education  is  suited  to  practices  in  which  an  understanding  of  how  inputs  affect  outputs  is 
needed  in  order  to  detennine  what  is  relevant  versus  what  is  irrelevant  before  deciding  on 
a  course  of  action.  Training  is  better  applied  to  processes  in  which  the  actions  required 
are  standardized  and  produce  consistent  results.  The  accuracy  of  these  virtual 
simulations  is  dependent  on  information  captured  by  collaborative  PLM  during  real- 
world  events. 


c.  Support 

Even  if  a  person  learns  something  during  education  and  training,  this  does 
not  guarantee  that  they  will  be  able  to  remember  it  when  that  infonnation  is  actually 
needed.  Support  functions  to  supplement  education  and  training  by  providing  a  network 
of  people  who  can  assist  in  searching,  recalling,  or  relearning  the  information  when 
required. 

John  Seeley  Brown,  the  fonner  director  of  Xerox  PARC,  provided  an 

interesting  analogy  concerning  the  support  function.  While  investigating  how  copier 

repair  technicians  solved  complicated  problems,  he  concluded  that  “when  the  going  gets 

tough,  the  tough  get  coffee”  (Brown  &  Duguid,  2002).  When  looking  at  morning  coffee 

breaks  from  a  LEAN  perspective,  a  logical  conclusion  is  that  coffee  breaks  were  non 

value-added  activities  and  technicians  should  seek  to  eliminate  them  to  improve 

efficiency.  However,  these  coffee  breaks  were  not  wasted  time.  Instead,  they  were  a 

support  activity  in  which  all  the  technicians  gathered  and  discussed  and  collectively 

58 


diagnosed  solutions  to  their  individual  problems.  Thus,  eliminating  the  coffee  breaks 
would  have  had  a  negative  effect  on  efficiency. 

Collaborative  PLM  needs  to  have  support  functions  that  provide  assistance 
for  product  information  as  well  as  control  how  the  supporting  technology  will  interact 
with  the  collaborative  PLM  suite  in  order  to  prevent  people  from  becoming  inefficient  or 
frustrated. 


3.  Information/Technology 

The  success  and  capability  of  any  particular  collaborative  PLM  application  is 
dependent  on  the  capability  and  availability  of  the  underlying  technology.  Availability 
refers  to  the  infrastructure  required  at  an  organization.  Obviously,  all  infrastructure  costs 
money  to  establish.  However,  establishing  the  proper  balance  is  necessary  to  get  a  good 
return  on  investment.  Excess  infrastructure  does  not  deliver  any  benefits,  so  the 
investment  is  wasted.  Meanwhile,  missing  infrastructure  will  restrict  access,  limiting  the 
potential  benefits.  People  will  find  workarounds  or  simply  avoid  the  system  if  it  lacks,  for 
example,  adequate  computing  power,  communications  bandwidth,  and  storage  capacity. 
Therefore,  proper  infrastructure  does  not  detennine  collaborative  PLM  success,  but 
improper  infrastructure  could  dictate  failure.  The  recommendations  contained  in  the 
following  chapters  do  not  try  to  determine  the  scale  of  proper  infrastructure  as  this  is 
dependent  on  the  extent  to  which  these  recommendations  are  applied. 

a.  Applications 

It  is  unlikely  that  one  of  the  relatively  few  collaborative  PLM  providers  is 
capable  of  developing,  providing,  and  updating  the  entire  collaborative  PLM  software 
suite  (as  well  as  all  the  applications  necessary  to  design,  build,  and  maintain  the 
shipbuilding  portfolio).  By  selecting  a  one-company  solution,  a  tremendous  amount  of 
risk  is  assumed  because  success  is  entirely  dependent  on  the  products,  quality,  and 
evolution  of  that  one  company.  A  better  strategy  is  to  develop  interoperability  standards 
so  that  applications  are  compatible  and  have  the  ability  to  transfer  and  use  data  amongst 
themselves. 
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Software  should  be  developed  to  reflect  how  people  do  their  jobs  versus 
people  changing  how  their  jobs  are  done  to  accommodate  the  easiest  way  to  program  the 
software.  The  collaborative  PLM  software  and  applications  should  be  embedded  into  the 
practices  and  processes  so  that  they  work  as  a  seamless  unit.  For  collaborative  PLM  to 
be  fully  embedded  into  practices  and  processes  and  adopted  by  the  workforce,  it  must  be 
completely  reliable  when  capturing,  retrieving,  and  using  product  data. 

b.  The  Virtualization  of  Physical  Objects 

Technology  development  has  experienced  an  unbelievable  trajectory, 
constantly  redefining  what  is  possible,  which  projects  very  well  for  the  future.  Briefly 
looking  at  this  progression,  we  can  begin  with  storytelling,  as  an  example,  storytelling 
would  be  error-prone  due  to  its  reliance  on  the  accuracy  of  the  teller,  as  well  as  the 
comprehension  of  the  receiver.  As  storytelling  progressed,  people  supplemented  the  oral 
description  with  pictures,  eventually  mastering  the  ability  to  create  physical  drawings 
showing  length,  width,  and  depth.  When  accompanied  by  other  data,  this  opened  up  the 
ability  to  create  physical  mockups  with  complete  accuracy.  However,  these 
advancements  still  had  limitations.  For  instance,  as  the  richness  of  information  increased 
from  descriptions  to  drawings  to  mockups,  the  time  needed  to  create  these  mockups 
increased,  as  did  the  resources  required  to  transport  them  across  the  geographically 
expanding  organizations.  With  computers  and  the  Internet,  the  resources  required  for 
transportation  have  decreased  substantially.  However,  these  drawings  and  models  were 
still  just  a  snapshot  of  the  design  at  a  moment  in  time.  Today,  it  is  possible  to  operate  in 
a  full  virtual  environment.  Designers  can  pick  up,  move,  make  changes  to,  and  interact 
with  the  design  as  if  it  was  a  real  object,  all  in  real  time. 

One  of  the  values  of  collaborative  PLM  comes  from  the  ability  to  access 
and  leverage  product  information  wherever  it  resides.  One  example  is  the  simulation 
software  that  supports  virtual  product  development  (VPD)  in  a  collaborative  PLM 
strategy,  notes  Bob  Ryan,  executive  vice  president,  of  MSC.  Software  Corporation 
(Teresko,  2004b).  According  to  Ryan,  the  VPD  facilitates  the  innovation  process,  “how 
to  design  products  for  form,  fit,  function  and  manufacturability.  As  part  of  an  optimal 


60 


collaborative  PLM  strategy  VPD  can  easily  and  effectively  relate  to  other  aspects  of  a 
product's  lifecycle,  such  as  inventory,  maintenance  and  related  considerations”  (Teresko, 
2004b,  p.  1). 

With  an  optimized  collaborative  PLM/VPD  strategy,  in  other  words, 
improving  the  integration  of  physical  and  virtual  building  and  testing  of  the  product,  the 
result  is  accelerated  innovation  and  greatly  reduced  risk  at  a  lower  cost.  To  maximize  the 
benefits  of  virtual  product  development,  Ryan  recommended  viewing  physical  “build- 
and-test”  as  a  complement  to  virtual  “build-and-test.”  An  example  of  Ryan’s 
recommendation  is  the  Boeing  777.  As  the  first  digital  aircraft,  it  went  beyond  the 
traditional  use  of  CAD  by  checking  form  and  fit  with  a  digital  mockup.  Boeing  then 
virtually  flew  the  aircraft,  checking  the  landing  gear  and  other  systems  functionality 
(Teresko,  2004a). 

Ryan  stressed  that  VPD's  goal  should  be  to  integrate  testing  automation 
into  the  mainstream  collaborative  PLM  environment.  His  advice:  Start  by  studying  how 
VPD  automation  can  solve  existing  design  problems.  The  second  step:  Research  the 
benefits  VPD  automation  can  bring  to  new  design  initiatives.  The  final  level  is  to  achieve 
the  ability  to  do  design  signoffs  by  using  simulation  instead  of  physical  tests.  The  end 
point  arrives  when  simulation  can  drive  all  of  the  product  definition  throughout  the 
supply  chain  (Teresko,  2004a,  p.  1). 

B.  CHAPTER  SUMMARY 

This  chapter  discussed  the  synergy  between  organization,  people,  infonnation, 
technology,  processes,  and  practices  and  the  impact  it  has  in  creating  a  successful 
organization.  A  program  manager  should  understand  the  differentiation  between  a 
process  and  practice  in  order  to  understand  what  and  how  adjustments  need  to  be  made 
and  to  know  what  a  software  vendor  is  promising  with  new  technologies.  A  process 
transforms  those  inputs  into  a  well-specified,  predictable,  consistent  set  of  outputs,  versus 
a  practice  where  inputs  and  outputs  are  fairly  well  defined,  but  how  they  are  transformed 
is  not.  Practices  rely  on  judgment  and  experience  and  often  do  not  occur  in  the  controlled 
environment. 
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When  people  within  our  organization  operate  with  good  intentions  and  are 
motivated  and  competent,  they  can  figure  out  a  way  to  improvise  and  will  make  even 
poor  processes  and  low  technology  work  for  them.  Some  of  the  characteristics 
contributing  to  an  employee’s  capability  can  be  enhanced  by  improving  their  experience, 
education,  training,  and  support. 

The  success  and  capability  of  any  particular  collaborative  PLM  application  is 
dependent  on  the  capability  and  availability  of  the  underlying  technology.  Software 
should  be  developed  to  reflect  how  people  do  their  jobs,  versus  people  changing  how 
their  jobs  are  done  to  accommodate  the  easiest  way  to  program  the  software.  The 
collaborative  PLM  software  and  applications  should  be  embedded  into  the  practices  and 
processes  so  that  they  work  as  a  seamless  unit.  For  collaborative  PLM  to  be  fully 
embedded  into  practices  and  processes  and  adopted  by  the  workforce,  it  must  be 
completely  reliable  when  capturing,  retrieving,  and  using  product  data.  The  selected 
collaborative  PLM  application  needs  to  fully  take  advantage  of  the  benefits  gained  by 
operating  in  the  virtual  environment;  the  upfront  effort  it  takes  to  build  a  rich 
environment  will  be  worthwhile,  as  correcting  errors  or  making  modifications  are 
substantially  cheaper  and  faster  than  perfonning  the  same  modification  to  a  physical 
product. 
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VI.  FUTURE  STATE  OF  DEFENSE  ACQUISITIONS: 
ESTABLISHING  A  HEALTHY  FOUNDATION 


This  chapter  focuses  on  reforms  that  will  create  a  healthier  organization  in  terms 
of  DoD  acquisition  processes,  ensuring  that  the  workers  have  the  knowledge  and 
flexibility  to  adjust  course  when  the  plan  begins  to  go  awry.  The  recommendations 
contained  below  are  not  explicitly  tied  to  the  deployment  of  collaborative  PLM,  but 
collaborative  PLM  offers  capabilities  magnifying  the  expected  benefits  of  these  reforms 
and  these  reforms  will  help  institutionalize  collaborative  PLM  applications,  which  can 
reduce  acquisition  costs  and  TOC. 

A.  CREATING  A  NATIONAL  DESIGN  ORGANIZATION  (NDO) 

In  1936,  Theodore  Paul  Wright  described  the  effect  of  learning  on  labor 
productivity  in  the  aircraft  industry  and  proposed  a  mathematical  model  of  the  learning 
curve,  Figure  12  (Wright,  1936). 
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The  theory  estimates  the  changing  rate  of  learning  during  a  set  activity  or  tool. 
Typically,  the  increase  in  retention  of  infonnation  is  highest  during  the  initial  attempts, 
and  then  gradually  evens  out,  meaning  that  less  and  less  new  information  is  retained  after 
each  repetition.  However,  today  each  new  acquisition  design  program  begins  at  the 
bottom  of  the  learning  curve,  because  each  program  is  initiated  by  forming  a  new  team 
with  many  members,  who  may  have  never  completed  a  ship  design  or  at  least  never 
worked  together  previously. 

Dan  Billingsley  would  like  to  change  this  practice  of  beginning  each  new  ship 
design  program  with  a  new  team,  and  when  we  discussed  this  inefficient  practice,  he 
stressed  the  need  for  an  organization  to  provide  sound  designs  in  response  to  the 
emerging  and  ever-changing  needs  of  the  entire  acquisition  portfolio  (D.  Billingsley, 
personal  communications,  April  5,  2010).  His  30  plus  years  of  experience  in  the 
acquisition  community  has  led  him  to  believe  that  a  single  design  organization  initiating 
each  new  design  would  have  a  series  of  positive  benefits.  The  main  function  of  a 
national  design  organization  (NDO)  would  be  to  provide  structure  and  leadership  during 
the  early  design  phases  and  deliver  trusted  products  (cost,  performance,  schedule,  and 
risk  estimates).  This  organization  should  be  comprised  of  representatives  from  each 
phase  of  the  lifecycle:  design,  production,  maintenance,  and  operation  domains. 
Applying  the  learning-curve  concept,  by  having  one  team  handle  all  the  designs,  this 
team  will  have  the  opportunity  to  learn  from  previous  mistakes  and  provide  a  design  to 
serve  as  a  solid  foundation  for  each  new  program.  The  NDO  would  also  serve  as  the 
custodian  for  each  of  the  reforms  contained  in  this  research. 

The  NDO  would  also  be  charged  with  grooming  new  engineers,  establishing  and 
maintaining  design  and  engineering  standards,  providing  a  focal  point  for  fleet  feedback, 
developing  and  maturing  analytic  tools  required  during  design  and  certification,  and 
ensuring  that  product  data  interoperability  standards  evolve  and  are  followed.  Billingsley 
contended  the  foundation  of  a  successful  program  would  be  established  by  having  every 
design  begin  under  the  same  roof,  ensuring  that  the  up  to  80%  of  TOC  set  by  those  early 
decisions  are  made  by  the  most  experienced  team  possible  (D.  Billingsley,  personal 
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communications,  April  5,  2010).  It  will  also  benefit  institutionalizing  collaborative  PLM 
as  the  design  team  will  become  very  familiar  and  comfortable  operating  in  its  virtual 
environment. 

During  a  meeting  with  the  DDG-1000  program  office  a  comment  was  made  that 
the  Navy  is  still  performing  a  majority  of  its  functions,  such  as  reviewing  drawings  or 
collaborating  on  documents,  outside  the  collaborative  PLM  environment  simply  because 
their  workers  were  unfamiliar  and  unconfident  completing  tasks  within  collaborative 
PLM  (J.  Watson,  personal  communication,  April  5,  2010).  This  hurdle  of  training  an 
organization  as  large  as  NAVSEA  and  the  Program  Offices  will  still  need  to  be  addressed 
and  will  actually  be  magnified,  as  eventually  that  list  will  be  expanded  to  include  sailors, 
vendors,  and  contractors  that  will  be  involved  with  the  ship  throughout  the  lifecycle.  The 
time  needed  to  train  individuals  until  they  are  comfortable  within  the  collaborative  PLM 
environment  will  not  only  take  away  time  from  actual  ship  design  tasks,  but  also,  until 
they  are  proficient  within  collaborative  PLM,  the  quality  of  those  tasks  could  also  be 
compromised.  The  NDO  should  be  responsible  for  conducting  the  preliminary  ship 
design  for  every  new  program,  as  the  decisions  made  during  this  portion  of  the  program 
have  dramatic  impacts,  the  design  should  be  conducted  by  a  team  that,  through  repetition, 
is  already  familiar  with  the  intricacies  of  collaborative  PLM  and  can  focus  solely  on  the 
quality  of  the  design.  The  NDO  can  build  a  solid  foundation  for  a  new  ship  program  so 
that  when  transferred  into  the  program  office’s  responsibility,  the  majority  of  the  critical 
decisions  have  already  been  made  to  reflect  the  best  interest  of  the  program  from  the  total 
lifecycle  perspective.  The  program  office  will  be  responsible  for  overseeing  the 
contractor  conducting  the  detail  design  and  construction. 

Lastly,  the  NDO  will  be  charged  with  supporting  the  process  during  follow-on 
stages  of  design  and  construction,  providing  continuity  to  the  new  ship  program,  and, 
most  importantly,  witnessing  the  ramifications  of  early  decisions  in  learning  and 
improving  the  process  (D.  Billingsley,  personal  communications,  April  5,  2010). 
Billingsley’s  position  is:  “our  organizations  have  become  very  product  centric.”  By  this, 
he  means  that  large  investments  will  be  made  in  order  to  gain  any  amount  of  value  when 
it  concerns  the  product:  for  instance,  the  large  investments  required  to  develop  a  new 
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technology  such  as  the  rail  gun.  Operating  the  organization  as  described  above  would 
assign  the  same  emphasis  on  improving  the  processes.  The  NDO  would  have  the 
repetitions  necessary  to  travel  up  the  collaborative  PLM  and  ship  design  learning  curves; 
they  would  be  familiar  with  the  collaborative  PLM  environment,  and  would  be  able  to 
leverage  the  capabilities  of  the  new  technology  to  improve  the  ship  design  process.  Once 
the  ship  design  process  is  improved  it  will  pay  dividends  across  all  product  lines,  present 
and  future  (D.  Billingsley,  personal  communications,  April  5,  2010).  Calling  for  a  design 
organization  does  not  require  disestablishment  of  the  program  offices  that  currently 
handle  new  acquisition  projects.  The  current  structure  of  program  offices  is  held 
accountable  mainly  to  the  acquisition  unit  cost  of  their  programs.  Once  the  preliminary 
design  is  complete,  it  can  be  transferred  to  the  program  office  and  contractors  for 
complete  detail  design  and  construction.  Mission  funding  the  NDO  as  a  standalone 
organization  would  allow  the  focus  to  be  placed  on  producing  the  best  design  for  the 
Navy  across  the  entire  lifecycle,  as  opposed  to  the  current  funding  structure,  which 
incentivizes  program  managers  to  prioritize  staying  below  acquisition  unit  cost 
thresholds. 

B.  GROOMING  AN  EXPERIENCED  DESIGN  WORKFORCE 

The  experience  of  a  design  team  can  be  an  influential  factor  of  project  success. 
Experience  can  overcome  many  shortfalls  and  seize  opportunity  when  it  presents  itself. 
Figure  13  is  from  a  study  demonstrating  how  an  experienced  design  team  building  one- 
of-a-kind  oil  platfonns  resulted  in  a  20-25%  cost  savings,  as  compared  to  an 
inexperienced  design  team  (Keane,  Fireman,  Hough,  Helgerson,  &  Whitcomb,  2008). 
Secretary  of  the  Navy  Winter  understood  this  concept.  He  emphasized  the  importance  of 
experience: 

Hiring  top  quality  people  who  have  experience  with  large  shipbuilding 
programs  is  essential.  The  ability  to  assign  an  experienced  and  capable 
team  must  be  a  precondition  to  a  program’s  initiation.  Finding  and 
developing  the  people  we  need  is  easier  said  than  done,  and  it  will  take 
time  to  rectify  this  problem,  but  we  cannot  ignore  the  leverage  that  can  be 
obtained  by  putting  the  right,  experienced  and  prepared  people,  in  the  right 
positions.  (Winter,  2007) 
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Figure  13.  Experience  of  Design  Team  Drives  Cost  Performance 

(From  Keane,  Fireman,  Hough,  et  al.,  2008) 


NAVSEA  has  successfully  maintained  a  core  of  highly  skilled,  experienced  ship- 
design  leaders.  However,  this  experienced  core  has  continued  to  age  since  the  hiring 
freezes  in  the  ’90s,  and  these  ship-design  leaders  are  beginning  to  retire  in  rather 
significant  numbers. 

In  FY2008,  15%  of  the  acquisition  workforce  was  eligible  for  retirement.  In  ten 
years,  this  will  climb  to  54%  among  current  employees  (Federal  Acquisition  Institute, 
2009).  Ben  Kassel,  currently  with  Naval  Surface  Warfare  Center  Carderock,  commented 
that  during  a  significant  portion  of  the  1990s,  NAVSEA  accomplished  its  downsizing 
mandate  by  limiting  new  hires,  a  decision  that  today  is  the  cause  of  another  problem. 
This  hiring  policy  created  a  gap  of  experienced  workers  who  today  would  be  capable  of 
assuming  all  the  duties  as  older  workers  retire  (B.  Kassel,  personal  communication,  April 
6,  2010).  The  response  has  been  hiring  a  large  number  of  entry-level  engineers.  While 
this  strategy  will  meet  the  full-time  equivalent  quota,  it  still  leaves  the  monumental  task 
of  ensuring  that  the  accumulated  knowledge  of  the  older  workforce  is  transferred  to  these 
new  hires.  Dan  Billingsley  estimates  that  it  takes  five  years  of  experience  before  an 
engineer  truly  understands  the  complexity  of  ships  and  can  contribute  to  the  design  effort 
(Billingsley,  2010).  Compounding  this  problem  is  the  fact  that  today’s  programs 
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currently  take  at  least  10-15  years  to  work  through  the  design  phase  (GAO,  2008b).  This 
means  a  new  hire  at  best  will  be  trained  by  an  experienced  worker  through  one  cycle,  but 
more  than  likely,  a  new  hire  will  only  experience  a  partial  cycle  before  assuming  the 
reins.  The  urgent  challenge  is  how  to  effectively  transfer  the  design  experience  to  this 
new  workforce. 

However,  what  these  new  hires  lack  in  experience,  they  have  the  ability  to 
compensate  for  by  being  comfortable  with  software  and  other  high-tech  tools  coming  into 
the  marketplace.  The  Navy  has  implemented  simulators  into  its  warfighter-training 
plans.  Ship  drivers,  pilots,  and  shooters  all  receive  simulator  training  as  a  cheap,  reliable, 
controlled  way  of  gaining  experience.  The  acquisition  community  does  not  have  a 
comparable  set  of  tools  to  train  workers  in  the  virtual  environment. 

Training  is  part  of  daily  life  in  the  Navy  and  should  be  part  of  the  NDO’s  life  as 
well.  Effective  training  has  the  ability  to  improve  on  the  estimated  five  years  needed  to 
gain  experience.  During  times  when  the  NDO  has  either  no  active  program  or  the  active 
program  does  not  require  the  entire  organization,  training  could  occur.  A  team  could  be 
assigned  to  design  a  major  project  to  near  production-level  detail,  and  then  evaluate  the 
design.  “Engineering  a  Solution  to  Ship  Acquisition  Woes,”  presented  the  following 
benefits  that  can  be  expected  by  conduction  of  this  type  of  exercise: 

•  The  exercises  serve  as  individual  and  organizational  training. 

•  The  exercises  help  ensure  familiarity  with  the  analytical  tool  kit  as  well  as 
areas  of  weakness. 

•  Being  able  to  experiment  with  new  design  processes  and  really  push  the 
envelope  would  be  possible  without  adding  risk  to  a  particular  program. 
Often,  more  is  learned  from  failure  than  from  success.  In  a  training  scenario, 
not  being  concerned  with  failure  could  lead  to  unexpected  breakthroughs. 

•  Since  schedule  is  not  an  issue,  several  iterations  of  a  design  could  be 
accomplished  to  fully  explore  the  trade  and  detennine  optimal  solutions. 

•  It  would  provide  the  opportunity  to  mature  design  products,  and  as  designs  are 
completed,  they  can  be  stored  as  a  digital  library.  Once  archived,  the  design 
can  be  reinitiated  and  modified  in  response  to  an  emerging  threat  or  need 
(Billingsley,  2010). 

The  military  conducts  war  games  constantly,  trying  to  forecast  the  future  and  make  sure 
that  we  are  never  caught  off  guard.  Yet  today  the  acquisition  community  is  conditioned 
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to  hop  from  one  active  program  to  the  next,  without  the  opportunity  to  plan,  prepare,  and 
train  adequately.  Implementing  design  exercises  can  correct  that  deficiency. 

A  second  benefit  of  these  design  exercises  is  that  true  innovation  cannot  be 
forced,  the  best  ideas  rarely  come  on  cue,  and  when  a  program  is  constrained  by  a 
schedule,  the  entire  design  space  is  rarely  explored,  before  having  to  moving  on.  These 
design  exercises  serve  to  capture  and  preserve  ideas  when  they  do  come.  A  collaborative 
PLM  suite  would  incorporate  this  “idea  bank”  to  capture  all  the  inspiration,  be  it  needs, 
products,  services,  processes,  policies,  or  insights  that  people  come  up  with,  but  are  not 
directly  related  to  the  current  efforts. 

Collaborative  PLM  has  extensive  vaulting,  search,  and  organizational  capabilities 
that  would  be  ideal  to  contain  this  knowledge  bank  and  ensure  that  it  is  easy  to  use, 
protected,  accessible,  and  captures  the  right  infonnation  so  that  the  ideas  can  be  searched 
later.  Collaborative  PLM  also  can  store  several  configurations  of  the  same  project.  For 
instance,  if  during  one  of  the  design  exercises,  a  decision  must  be  made  concerning  a 
tradeoff  between  two  technologies  that  will  take  the  project  in  different  directions, 
collaborative  PLM  offers  the  designers  a  unique  way  of  addressing  the  decision.  Inside 
the  collaborative  PLM  architecture,  both  alternatives  can  be  worked  simultaneously  by 
creating  a  snapshot  of  the  project  at  that  point  in  time,  duplicating  it,  and  then  exploring 
both  alternatives.  This  will  help  ensure  that  the  entire  trade  space  is  explored  and 
prevents  delays  if  one  of  the  alternatives  turns  out  to  be  a  dead  end. 

Each  design  exercise  does  not  have  to  start  as  a  clean  sheet  design.  Rather,  they 
can  offer  the  opportunity  to  iterate  through  designs,  leveraging  the  contents  of  the  idea 
bank,  evaluating  and  evolving  ideas  to  either  match  current  threats,  integrate  new 
technologies,  or  correct  deficiencies.  The  idea  is  that  when  an  actual  design  is  needed,  a 
majority  of  the  work  has  already  been  accomplished;  thereby  shortening  time  elapsed 
before  it  can  be  delivered  to  the  warfighter.  Or,  by  making  the  best  use  of  the  schedule  to 
explore  the  entire  trade  space,  the  design  would  be  optimized  to  ensure  that  it  is  the  best 
design  capable. 
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At  the  Naval  Postgraduate  School  (NPS),  students  volunteer  to  participate  in  a 
design  exercise  referred  to  as  the  total  ship  systems  engineering  (TSSE)  project.  It  is  a 
design  exercise  as  described  above.  The  intention  is  to  give  experience  to  students  who 
will,  upon  leaving  NPS,  work  in  the  acquisition  community  on  active  programs.  The 
students  are  provided  a  project  that  addresses  a  need  of  the  Navy;  they  then  attempt  to 
work  through  the  entire  design  process,  from  a  clean  sheet  to  a  presentable  design.  With 
proper  structure,  this  program  could  be  improved,  to  not  only  expand  the  student 
experience,  but  also  to  deliver  something  valuable  to  the  Navy.  The  previous  student 
design  team  commented  that  the  exercise  lacked  sufficient  mentorship  from  the 
acquisition  community.  They  made  an  assumption  because  they  did  not  have  access  to 
the  appropriate  data,  then  discovered  during  their  final  presentation  that  the  assumption 
was  incorrect,  invalidating  their  design  proposal.  My  group  is  having  a  similar 
experience  as  we  are  halfway  through  our  design  exercise,  and  we  have  not  interacted 
with  the  stakeholders  of  our  design  concept.  Once  the  NDO  is  formulated,  part  of  their 
task  should  be  to  mentor  this  and  other  TSSE  programs  across  the  country.  One  of  the 
strengths  of  collaborative  PLM  is  that  since  it  is  web  based,  NPS  could  purchase  a  seat  on 
the  NAVSEA  Integrated  Data  Exchange  (IDE)  and  use  the  same  idea  bank,  design  tools, 
common  parts  catalogue,  social  networking,  and  support  that  actual  NAVSEA  engineers 
are  using.  These  would  not  only  improve  the  TSSE  program  with  regards  to  student 
education,  but  perhaps  the  students  could  accomplish  something  of  actual  value  for 
NAVSEA. 

C.  PRODUCT  DATA  INTEROPERABILITY  (PDI) 

The  last  two  sections  recommended  reforms  such  as  creating  the  NDO  and  used 
design  exercises  to  groom  inexperienced  workers  through  training  exercises.  Next,  we 
will  move  into  ways  to  assist  the  people  and  design  organization  in  their  direct  efforts  on 
executing  value-added  tasks  of  the  ship-development  process.  Daniel  Billingsley  has 
defined  these  value-added  tasks  as  “knowledge-work  and  analysis,  decision-making,  and 
problem  solving  associated  with  development,  construction,  and  support  during  the 
service  life”  (Billingsley,  2006).  In  several  white  papers  and  most  recently  at  the  ASNE 

symposium,  he  estimated  that  in  NAVSEA,  this  knowledge  work  accounts  for 
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approximately  one-third  of  their  total  obligation  authority,  or  $7.2  billion  each  year  (D. 
Billingsley,  personal  communications,  April  5,  2010).  This  is  a  significant  portion  of  the 
budget  and  is  a  prime  area  to  look  for  improvements. 

Studies  have  shown  that  50-90%  of  a  knowledge  worker’s  time  is  spent  on  non¬ 
value-added  preparatory  tasks  (locating,  retrieving,  verifying,  transforming,  and 
recreating)  and  then  follow-on  tasks  (recording,  distributing,  and  storing)  (Keane,  2007). 
By  eliminating  or  reducing  these  non  value-added  activities,  either  cycle-time  can  be 
reduced  or  more  time  can  be  allocated  to  improving  the  product;  either  scenario  is 
beneficial. 


The  amount  of  preparatory  and  follow-on  tasks  stems  from  the  organization 
necessary  to  handle  the  immense  and  overwhelming  amount  of  data  involved  in  a 
warship  design.  One  of  the  challenges  is  efficiently  getting  the  right  data  to  the  right 
person  when  needed  so  that  it  can  be  used  productively.  Programs  recently  have  begun  to 
design  integrated  product  development  environments  (IPDE)  to  support  integrated 
information  processing  to  address  this  challenge.  IPDEs  are  systems  that  have  both  3D 
product  data  and  management  capabilities,  in  addition  to  document-management 


capabilities.  Figure  14  shows  the  IPDE  created  for  the  LPD  17  program  (Murphy,  1997). 
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Level  I  -  Product  Model  Data  (3D  Geometry  +  Attributes) 

Level  II  -  Support  Data  (Vendor  Information,  Manuals,  GFI,  etc.) 
Level  IE  -  Program  Execution  Data  (MIRWS,  IMP,  C/SCS,  etc.) 


Figure  14.  LPD  17  IPDE 

(From  Murphy,  1997) 
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These  environments  are  very  similar  to  the  collaborative  PLM  suites  discussed  in 
Chapter  II,  but  seem  to  lack  the  total  lifecycle  perspective  that  was  common  in  the 
collaborative  PLM  suites  evaluated.  The  IPDE’s  were  created  and  used  during  the  design 
and  manufacturing  phases  of  a  program,  but  were  not  designed  to  be  transferred  and  used 
during  the  operation  and  sustainment  phases.  For  instance,  the  designers  did  not  design 
the  IPDEs  to  capture  and  leverage  the  knowledge  learned  or  the  problems  experienced  by 
the  ship  operators  or  maintainers,  nor  were  3D  product  models  available  to  the  operators 
or  maintainers  (P.  Hudson,  personal  communication,  April  6,  2010). 

1.  Program-Specific  IPDEs  are  Less  Than  Ideal 

Whether  integrated  into  a  collaborative  PLM  suite  or  as  a  stand-alone  unit,  IPDEs 
have  promising  upsides.  However,  significant  software  developmental  and  integration 
challenges  are  also  present.  There  are  several  Commercial  Off-the-shelf  (COTS)  IPDEs 
and  collaborative  PLM  options.  However,  due  to  the  complexity  of  information  being 
processed  and  the  limited  market,  none  of  them  are  specifically  tailored  to  support  naval 
ship  programs.  This  means  that  shipbuilders  and  programs  independently  work  with  the 
vendors  to  build  IPDEs  from  COTS  components  and  custom  interfaces.  For  a  major 
shipbuilding  program,  the  IPDE  could  total  $150-200  million,  of  which  45-55%  is 
integration  planning,  information  engineering,  and  interface  software  development 
(Keane,  Fireman,  &  Billingsley,  2007).  With  each  program  office  paying  to  custom  build 
its  IPDE  to  meet  its  requirements,  processes,  relationships,  and  to  take  advantage  of  the 
latest  hardware  and  software  developments,  there  are  no  incentives  to  build 
interoperability  or  lifecycle  features.  In  “Ready  to  design  a  Naval  ship?  Prove  it!”  Keane, 
Fireman,  Hough,  Helgerson  and  Whitcomb  outlined  various  problems  associated  with 
this  ad  hoc  process: 

•  Duplication  of  development  effort  across  many  programs, 

•  Multiple  partially  integrated  systems  that  are  not  interoperable  with  others, 

•  Annual  integration  expenses  of  $  10-30  million  for  each  major  program, 

•  Multiple  incompatible  systems  at  each  shipyard,  and 

•  Numerous  inconsistent  sources  of  product  information  for  Navy  engineering 
and  support  during  the  service  life.  (Keane,  Fireman,  Hough,  et  ah,  2008) 
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An  assumption  can  be  made,  that  because  many  of  the  recent  acquisition 
programs  have  taken  on  the  expense  to  create  individual  IPDEs,  they  assessed  the 
capabilities  and  determined  the  benefits  were  greater.  However,  these  tools  would  be 
even  more  powerful  if  they  had  the  ability  to  leverage  knowledge  and  effort  across  the 
entire  enterprise,  versus  being  limited  to  their  own  programs.  Creating  a  Navy  enterprise 
IPDE  would  eliminate  each  of  the  problems  discussed  above. 

2.  The  Need  for  Standards,  not  Selection 

The  enterprise-wide  solution  could  be  accomplished  in  several  different  ways. 
The  Navy  could  pick  a  particular  vendor  to  create  the  entire  enterprise-wide  solution. 
Another  way  could  be  for  various  vendors  to  operate  under  the  same  PDI  standards.  The 
first  option  is  unadvisable,  because  it  puts  a  tremendous  amount  of  pressure  on  selecting 
the  appropriate  vendor,  as  once  that  vendor  has  a  monopoly  on  the  market,  there  is  less 
incentive  to  improve  its  product  to  meet  evolving  needs  or  shortcomings.  The  more 
advisable  solution  is  to  spend  the  time  and  effort  to  ensure  that  all  of  our  data,  regardless 
of  what  particular  software  vendor  is  being  used,  is  transferable  between  platfonns. 

Investment  in  PDI  from  1986  through  2004  totaled  approximately  $61.3  million, 
$26.3  million  of  which  was  used  directly  by  the  Navy.  The  original  focus  was  on 
transferring  CAD  data  between  shipyards  to  support  the  “lead-yard,”  “follow-yard” 
business  model  (Keane,  Fireman,  Hough,  et  al.,  2008).  Billingsley  (2006)  argued  that  an 
enterprise-wide  strategy  for  product  interoperability  has  certain  benefits  over  individual 
IPDEs,  including: 

•  Enable  introduction  of  improved  and  third-party  capability  in  specific  areas, 
including  discipline-focused  software  developed  by  ABS,  Office  of  Naval 
Research  (ONR),  Defense  Advanced  Research  Projects  Agency  (DARPA), 
academia,  and  industry. 

•  Reduce  or  eliminate  the  need  for  multiple  IPDEs  within  a  single  yard. 

•  Enable  acquisition  programs  to  re-use  engineering  tools  and  data-management 
components  developed  by  preceding  programs. 

•  More  flexibility  in  teaming  and  second-sourcing. 

•  Expedited  review  of  shipbuilder  designs  by  government  engineering  agents. 
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•  Enabling  common  methods  of  handling  product  data  for  support  during  the 
service  life. 

•  Ability  to  utilize  archived  data  in  current-generation  systems  (Billingsley, 
2006). 

3.  Impact  of  product  data  interoperability  (PDI) 

The  benefits  to  the  shipbuilding  enterprise  and  timing  of  pay  back  can  be  hard  to 
quantify.  Three  attempts  have  been  made  to  quantify  the  savings  once  PDI  is  achieved; 
the  results  vary  between  $150-450  million  (Billingsley,  2006). 

Achieving  product  data  interoperability  will: 

•  Make  cross-program  collaboration  possible, 

•  Allow  the  Navy  to  control  policies  and  contract  terms  for  product  data  for 
acquisition  and  support  during  the  service  life, 

•  Format  data  to  be  useful  during  each  phase  of  lifecycle, 

•  Enable  communication  of  shipbuilder  designs  to  NAVSEA  for  design  review 
and  certification, 

•  Enable  NAVSEA  to  give  guidance  focusing  on  software  development  by 
ABS,  ONR,  DARPA,  universities,  and  industry, 

•  Enable  acquisition  programs  to  re-use  engineering  tools  and  data  management 
components  developed  by  preceding  programs, 

•  Enable  common  methods  of  handling  product  data  for  support  during  the 
service  life.  (Keane,  Fireman,  Hough,  et  ah,  2008) 


PDI  will  not  itself  solve  any  of  the  issues  that  are  leading  to  the  unsustainable  cost 
growth  or  the  unrealized  TOC  being  experienced  today  because  it  deals  only  with  the 
transferability  of  data.  However,  all  of  the  solutions  depend  on  the  efficient  flow  of 
quality  information  throughout  the  enterprise.  Program  risk  will  be  reduced  by  cost 
savings  associated  with  eliminating  the  need  for  expensive  translators  that  must  be 
updated  frequently  to  account  for  software  updates.  Technical  risk  will  be  reduced 
because  technical  warrant  holders  will  not  have  to  waste  time  transferring  and  translating 
data  before  analyzing  it  (R.  Keane,  personal  communication,  April  8,  2010).  Programs 
will  be  able  to  re-use  designs,  eliminating  the  need  to  start  with  a  blank  sheet  of  paper 
each  time.  Managers  will  have  an  easier  time  approving  data  because  it  will  always  be  in 
the  same  fonnat. 
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The  Virginia  Class  program  should  serve  as  a  model  for  how  to  achieve  PDI. 
Congress  decided  that  two  submarine  yards  are  required  for  national  strategic  reasons.  In 
February  1997,  Electric  Boat  and  Newport  News  Shipbuilding  entered  into  an  unusual 
co-production  team  arrangement  (see  Figure  15).  The  construction  is  split  evenly 
between  the  two  yards  with  each  alternating  as  the  lead  integrator.  Each  yard  is  operating 
a  collaborative  PLM  system  and  have  successfully  shared  data  and  collaborated  between 
the  two  yards  during  execution  of  this  program.  Collaborative  PLM  allowed  them  to 
work  from  one  design  even  though  they  were  geographically  separated.  Their  efforts 
ensured  no  surprises  occurred  as  they  constructed  components  in  one  yard,  put  them  on  a 
barge,  and  shipped  them  to  the  other  yard  for  assembly  (General  Dynamics  Electric  Boat, 
2002). 
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Figure  15.  Workflow  Between  Electric  Boat  and  Newport  News 

(From  General  Dynamics  Electric  Boat,  2002) 


While  PDI  will  not  solve  any  problems,  the  lack  of  it  is  a  barrier  that  could 
prevent  other  reforms  from  being  successful.  The  Navy  will  not  realize  all  the  benefits  of 
collaborative  PLM  if  the  data  is  not  interoperable  and  knowledge  can  be  leveraged  across 
the  entire  portfolio. 
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D.  DESIGN  AND  CERTIFICATION  TOOLS 

Just  as  the  small,  specialized  shipbuilding  market  makes  necessary  the 
development  of  a  customized  collaborative  PLM  suite,  it  also  means  the  industry  cannot 
expect  the  associated  tools  and  applications  needed  to  support  the  design  and  technical 
warrant  holders  to  be  developed  without  the  guidance  and  investment  of  the  Navy.  This 
is  yet  another  reason  to  support  data  standards  and  interoperability,  as  it  would  allow 
myriad  sources  (public,  private,  and  academic)  to  develop  tools  in  a  fashion  that  would 
ensure  they  are  capable  of  being  integrated  into  the  collaborative  PLM  suite  while 
eliminating  the  translators  and  the  recoding  traditionally  required  to  ensure  compatibility. 
Independent  of  the  design  source,  a  mature  tool  kit  is  critical,  because  by  the  end  of  the 
design  phase,  80%  of  TOC  is  set,  so  those  early  decisions  can  offer  the  greatest  potential 
or  dire  consequences  (Briggs  et  al.,  2009).  Collaborative  PLM  is  going  to  be  able  to 
capture  and  organize  data  that  our  programs  have  never  had  before.  Real  world  data 
collected  from  operational  ships  can  be  statistically  analyzed  to  determine  what  are  the 
most  important  predictive  metrics  to  track. 

Keane,  Mclntire,  Fireman,  and  Maher  (2009)  argue  that  operational  architecture 
tools  such  as  those  being  developed  by  the  NAVSEA  Future  Concepts  and  Surface  Ship 
Design  Group  could  address  the  shortcomings  of  the  ship  synthesis  models  that  existed  at 
the  time  of  the  LPD-17  cost  and  operational  effectiveness  analysis  (p.  49). 

When  comparing  ship  options,  a  better  understanding  of  what  options  are  optimal 
is  needed.  Tools  (algorithms)  exist  that  optimize  the  design  parameters  of  a  ship  concept. 
Keane,  Mclntire,  et  al.  discuss  two  of  these  tools.  Georgia  Tech’s  Unified  Trade 
Environment  method  thoroughly  searches  the  entire  design  solution  space  better, 
calculating  differences  between  various  ship  options.  Virginia  Tech’s  Overall  Measure 
of  Effectiveness  enables  the  prioritizing  and  quantifying  operational  requirements  to 
drive  the  design  optimization  computations.  Prioritization  of  requirements  was  achieved 
by  a  pair-wise  comparison  hierarchy  with  experienced  operators,  ship  designers,  and 
program  managers  from  a  wide  range  of  disciplines  (Keane,  Mclntire,  et  al.,  2009,  p.  49). 
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Numerous  options  need  to  be  studied  prior  to  settling  on  a  new  ship  concept.  The 
quicker  each  of  these  options  can  be  created  and  evaluated,  the  more  iterations  can  occur, 
creating  the  potential  for  a  better  product.  The  tools  that  project  a  particular  concept’s 
technical,  risk,  and  cost  characteristics  must  produce  consistent,  trusted  results  or 
decision-makers  cannot  possibly  make  a  sound  evaluation  based  on  merits. 

1.  Current  Tools  Need  Development 

NAVSEA  can  improve  the  design  and  engineering  tools  and  applications 
available  to  assist  its  engineers  in  making  sound  decisions,  while  evaluating  the  multiple 
options  of  a  particular  design.  Ship  design  concepts  are  an  accumulation  of  decisions 
evaluating  particular  systems  or  components  against  a  set  of  requirements  and 
assumptions.  Each  criteria  used  to  make  a  decision  is  another  axis,  that  when  combined, 
forms  a  point  in  multi  dimensional  design  space.  Each  iteration  of  the  design  provides  the 
opportunity  to  change  one  of  the  variables,  creating  a  new  point  forming  the  field 
showing  what  is  possible  (Billingsley,  2006).  This  is  a  good  method  to  validate  certain 
assumptions  and  to  decide  which  point  estimate  is  best.  There  is  minimal  risk  while 
extrapolating  between  the  point  estimates.  However,  as  demonstrated  by  Figure  16,  there 
is  no  guarantee  that  the  point  estimates  calculated  contain  the  optimal  solution,  and 
extrapolation  beyond  the  points  introduces  a  tremendous  amount  of  risk. 


Figure  16.  Conventional  Approach  for  Design  Space  Exploration 

(From  Billingsley,  2010) 
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Current  early  stage  ship-design  tools  have  the  following  deficiencies  for  rough 
order  of  magnitude  (ROM)  and  feasibility  level  studies: 

•  Inability  to  conduct  real-time  cost  assessments, 

•  Inability  to  assess  total  ship  survivability  at  the  concept  level, 

•  Inability  to  conduct  topside  design  assessments  at  the  concept  level, 

•  Inability  to  conduct  weapon  systems-effectiveness  assessments, 

•  Inability  to  conduct  preliminary  ship-manning  analysis, 

•  Inability  to  analyze  a  wide  range  of  unconventional  hull-form  alternatives, 

•  Inability  to  conduct  preliminary  maneuverability  assessments, 

•  Inability  to  conduct  rapid  design  space  exploration  in  order  to  narrow 
down  the  range  of  acceptable  ship  concept  alternatives,  and 

•  No  flexibility,  transparency,  or  scalability  (Billingsley,  2006) 

2.  Impact  Once  Completed 

Over  the  past  several  years,  the  Navy  has  been  attempting  to  address  these 
shortcomings,  but  it  needs  to  continue  to  fund  the  efforts  into  design  space  exploration 
using  response  surface  methodology  (RSM)  (Billingsley,  2006).  This  new  approach 
leverages  the  power  of  computers  to  automate  the  systematic  exploration  of  the  design 
space,  once  enough  data  is  entered  into  the  system,  the  computer  can  cycle  through 
various  combinations,  testing  them  virtually.  It  would  be  cost  prohibitive  to  build  a  mock 
up  and  test  physically  the  number  of  combinations  that  a  computer  can  cycle  through; 
however,  a  computer’s  virtual  modeling  could  enable  the  decision-makers  to  decide 
which  combinations  would  be  valuable  to  test  physically  and  which  options  should  be 
eliminated  from  consideration.  This  increased  information  decreases  the  risk  of 
interpolation  and  allows  for  the  selection  of  the  truly  optimized  solution,  meeting 
competing  objectives  (Figure  17).  Continuing  to  mature  these  technologies  is  critical,  but 
it  is  only  half  of  what  is  needed.  Collecting  data  throughout  a  ship’s  lifecycle  is  a 
necessity  so  that  these  models  can  be  validated  and  trusted. 
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Figure  17.  New  Approach  for  Design  Space  Exploration 

(From  Billingsley,  2010) 


The  designers  and  technical  warrant  holders  must  respond  to  all  program  requests, 
regardless  of  the  stored  format  of  the  data.  If  each  program  collects  different  information 
and  stores  it  in  a  different  format,  (i.e.  the  data  lacks  interoperability),  the  process 
becomes  more  difficult.  This  scenario  would  require  the  retrieval  of  the  data,  and  then  the 
translation  of  data  so  that  it  can  be  evaluated  in  the  format  required  for  the  particular  tool 
being  used.  Then,  after  the  analysis,  the  data  must  be  converted  back  into  its  original 
form  and  assimilated  back  into  the  original  program,  so  that  it  can  be  used.  Those  are  all 
wasted  steps  that  require  time  and  effort.  PDI  will  eliminate  these  wasted  efforts  to  allow 
the  time  to  be  spent  either  conducting  a  more  thorough  analysis  or  the  elimination  of  an 
option,  thus  reducing  cycle-time,  both  of  which  are  beneficial. 

Once  these  tools  are  integrated  into  the  collaborative  PLM  suite,  they  will  have 
the  access  to  the  lifecycle  data  needed  as  the  suite  is  populated,  providing  the  ability  to 
refine  and  evolve  these  tools,  making  them  accurate  and  reliable.  Quantifying  direct  cost 
savings  from  a  more  comprehensive  set  of  design  and  certification  tools  is  difficult,  but  it 
is  possible  to  see  how  the  effort  would  lead  to  savings.  During  the  lifecycle,  savings 
could  come  from  providing  tools  where  none  currently  exist  in  order  to  allow  the 
evaluation  of  failures  that  have  not  been  analyzed  before.  Lifecycle  savings  would  also 
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come  from  uncovering  and  correcting  design  issues  before  they  ever  reach  the  fleet.  The 
investment  required  to  develop  good  software  is  insignificant  compared  to  the  cost  of  a 
failed  system  once  in  service. 

E.  SECTION  SUMMARY 

This  chapter  focused  on  reforms  of  the  organization  and  the  tools  and  people  that 
comprise  it,  recreating  a  National  Design  Organization  will  be  the  lynchpin  for  any 
lasting  reforms  of  the  acquisition  process.  An  NDO  would  provide  the  focus  and 
authority  necessary  to  make  meaningful  changes  and  address  many  of  the  weaknesses.  It 
makes  sense  then  that  the  most  experienced  well-trained  individuals  can  make 
appropriate  decisions,  essentially  locking  in  success,  before  transferring  the  project  into 
the  larger  program  offices  of  current  operations.  Once  this  organization  is  in  place,  many 
of  the  other  reforms  outlined  begin  to  fall  into  place  with  minimal  effort.  For  instance, 
the  next  wave  of  engineers  can  be  mentored  through  various  design  exercises  by  the 
experienced  engineers,  building  not  only  the  digital  idea  bank,  but  their  own  experience 
and  knowledge.  PDI  will  be  easier  to  resolve,  because  all  product  data  will  originate 
inside  the  same  organization,  ensuring  consistency.  This  consistency  will  facilitate  data 
transfer  between  programs  and  throughout  the  lifecycle,  as  well  as  provide  standards  for 
private  or  public  development  of  the  next  generation  of  collaborative  PLM  or  design 
tools. 
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VII.  FUTURE  STATE  OF  DEFENSE  ACQUISITIONS: 
ESTABLISHING  SOUND  PRACTICES  AND  PROCESSES 

This  chapter  will  focus  on  some  reforms  that  could  have  a  dramatic  effect  on  the 
ship  acquisition  process.  These  reforms  look  at  the  practices  and  processes  of  the  ship 
design  and  acquisition  process  and  how  they  can  be  modified  to  leverage  the  capabilities 
of  collaborative  PLM  applications.  Many  of  these  incorporate  lessons  learned  that  have 
proven  effective  in  other  industries  and  can  be  adapted  to  shipbuilding. 

A.  RECTIFY  LACK  OF  EARLY  SYSTEMS  ENGINEERING:  DECISIONS 
MADE  BEFORE  MILESTONE  B 

The  proper  business  case  of  a  ship  design  program  should  stress  the  application  of 
LEAN  design  principles  as  early  as  possible.  During  these  early  stages,  the  flexibility  to 
change  design  is  highest,  because  as  a  design  progresses  into  more  detailed  phases,  the 
cost  to  make  changes  increases.  The  National  Shipbuilding  Research  Program  (NSRP) 
developed  a  strategic  investment  plan  (SIP)  outlining  a  business  case  with  two  main 
objectives:  1)  focus  on  the  application  of  LEAN  concepts  to  the  preproduction  areas  of 
design,  thereby  reducing  cycle-time,  non  value-added  activities,  and  the  cost  of  ships;  and 
2)  focus  leadership  on  process  improvement,  which  is  needed  due  to  the  multi¬ 
organization  efforts  required  to  change  design  practices  that  are  deeply  embedded  in  the 
enterprise  culture  (Keane,  Fireman,  Hough,  et  ah,  2008). 

In  2006,  the  DoD  established  a  mandatory  sustainment  key  performance 
parameter  (KPP)  requirement  for  acquisition  systems.  The  KPP  has  three  main  factors: 
system  availability,  reliability,  and  ownership  costs.  The  Defense  Science  Board  gave 
the  following  recommendation  in  its  May  2008  report: 

The  single  most  important  step  necessary  to  correct  high  suitability  failure 
rate  is  to  ensure  programs  are  fonnulated  to  execute  a  viable  system 
engineering  strategy  from  the  beginning,  including  a  robust  reliability, 
availability,  maintainability  (RAM)  program,  as  an  integral  part  of  design 
and  development.  No  amount  of  testing  will  compensate  for  deficiencies 
in  RAM  program  formulation  (Under  Secretary  of  Defense  (AT&L), 

2008). 
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However,  the  current  practice  lacks  focus,  and  many  programs  pass  through 
milestone  B  (entry  into  the  engineering  and  manufacturing  development  phase),  without  a 
true  understanding  of  the  technical  risk  and  projected  TOC  of  the  design,  which  can  lead 
to  cost  and  schedule  growth  during  acquisition  and  higher  than  anticipated  operating  and 
maintenance  costs,  once  transferred  to  the  fleet. 

Several  characteristics  of  the  current  acquisition  structure  drive  this  behavior. 
First,  the  unnecessarily  long  cycle -time  (15  plus  years  for  some  programs).  To 
compensate  for  the  long  developmental  time,  programs  must  forecast  technology  that  will 
be  innovative  15  years  from  now.  This  incorporates  a  high  degree  of  technical  risks. 
Second,  because  a  program  must  be  fully  funded,  managers  underestimate  costs  and  risk 
in  order  to  sell  the  program  and  be  established.  This  competition  for  funds  has  led 
program  managers  to  trade  off  lifecycle  cost  or  capabilities  to  keep  acquisition  costs 
down.  Lastly,  even  when  overruns  and  delays  come  to  light,  the  program  keeps  going 
fueled  by  optimistic  “fix-as-you-go”  strategies,  preventing  the  fiscal  and  political  fallout 
associated  with  killing  a  program  (R.  Keane,  personal  communication,  April  8,  2010). 
Pushing  forward  programs  containing  so  much  risk  forces  the  government  into  cost-plus 
contracts,  because  no  company  can  estimate  a  firm  price  on  a  design  that  is  still  evolving. 

All  three  of  these  issues  can  be  addressed  by  limiting  the  developmental  time  to 
no  longer  than  six  years  from  milestone  A,  which  signifies  the  start  of  technology 
development  to  low-rate  initial  production  as  recommended  by  the  Deputy  Secretary  of 
Defense  (“Assessment  Panel  of  the  Defense  Acquisition  Performance  Assesment 
Project,”  2006). 

The  Virginia  Class  (SSN  774  class)  program  has  demonstrated  that  this  cycle¬ 
time  is  achievable,  due  to  the  effects  of  electronic  design  technology  and  integrated 
product  and  process  development  (IPPD)  implementation.  Electric  Boat  reports  that  USS 
Ohio  took  more  than  13  years  and  used  2,100  designers.  USS  Seawolf  took  about  13.5 
years  and  1,850  designers.  USS  Virginia  will  have  taken  about  9  years  and  1,150 
designers.  The  Electric  Boat  Virginia  Class  IPPD  program  manager  suggested  that  future 
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advances  that  incorporate  more  knowledge-base-driven  design  might  further 
revolutionize  the  design  process,  cutting  it  to  4.5  years  at  50%  the  current  manpower 
(General  Dynamics  Electric  Boat,  2002). 

With  the  shorter  cycle-time,  the  program  requirements  will  more  accurately 
reflect  what  the  warfighter  needs  because  there  is  less  time  for  trends,  missions,  and 
threats  to  change.  The  shorter  cycle  will  force  immature  technologies  out  of 
consideration  because  programs  no  longer  would  have  the  schedule  to  allow  these 
technologies  to  mature. 

Some  other  reforms  are  necessary  in  order  to  make  this  five-year  timeline 
realistic.  First,  it  will  be  best  to  leave  the  technology  development  as  the  responsibility  of 
the  research  labs,  such  as  the  ONR  and  DARPA.  The  time  spent  maturing  immature 
technology  can  be  eliminated  from  the  schedule.  Because  all  designs  begin  in  the  NDO, 
relationships  can  be  established,  fostering  not  only  a  smooth  transfer  of  technology  but 
also  a  focus  point  for  the  warfighter,  feeding  needs  and  desires  into  the  design.  Once  the 
NDO  has  its  tasking,  it  can  reach  into  collaborative  PLM’s  virtual  idea  hank  and  pull 
either  a  similar  design  or  components  from  many  designs  to  incorporate  into  the  new 
program.  Because  the  NDO  handles  all  new  design,  its  engineers  will  be  intimately 
familiar,  from  all  the  previous  designs  and  exercises  that  they  have  completed,  with  both 
what  is  available  in  tenns  of  the  common  component  catalog,  as  well  as  what  works  and 
what  does  not.  This  experience  will  help  them  turn  out  a  better  design,  while  setting  the 
pace  to  meet  the  five-year  goal.  Finally,  as  long  as  the  funding  stream  for  the  NDO  is 
established  intelligently,  they  can  be  held  accountable  based  on  the  quality  of  the  design 
and  avoid  the  pressure  today’s  program  managers  experience  when  meeting  spending 
limits.  This  pressure  is  understood  and  even  drove  the  previous  reform,  separating  the 
technical  warrant  holders  responsible  mainly  for  safety  of  ships  and  the  program 
managers  held  accountable  for  cost  and  schedule. 
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B.  USING  STANDARD  COMPONENTS  AND  PRODUCT  STANDARDS 

We  referred  to  the  common  parts  catalog  earlier  and  will  discuss  it  further  in  this 
section.  Today,  the  Navy  has  to  design,  buy,  and  support  thousands  of  different  pump 
valves  for  surface  ships  and  hundreds  of  different  electrical  controllers.  Leveraging 
previous  designs  and  components  needs  to  become  a  standard  process  during  early  stage 
design.  The  “Affordability  Through  Commonality”  Program  highlighted  the  benefit  of 
reducing  the  proliferation  of  similar  parts  in  the  fleet  (Billingsley,  2010).  When  each  of 
our  programs  is  operating  in  a  fully  integrated  collaborative  PLM  environment  with  a 
common  parts  list,  designer  A  can  drag  and  drop  a  part  or  even  an  entire  system  created 
by  designer  B  for  a  different  program  and  save  all  the  engineering  cost  to  redesign,  retest, 
and  revalidate  an  identical  part  from  scratch.  Perhaps  some  of  the  savings  can  be  spent 
upgrading  or  optimizing  the  part  or  system  to  increase  value.  This  improved  part  now 
becomes  the  new  common  part  that  designer  C  will  use  in  a  future  project.  Savings  will 
cascade  throughout  the  lifecycle  as  use  is  made  of  a  common  parts  catalogue.  The 
program  manager  will  have  risk  reduced  (cost,  schedule,  and  performance)  as  the  design 
matures  and  a  real  history  is  created.  Manufacturing  will  have  one  assembly  line  that  it 
must  keep  open.  Supply  will  have  fewer  spare  parts  to  purchase,  store,  inventory,  and 
ship.  Operators  will  have  fewer  systems  to  learn  how  to  operate  and  maintain. 
Maintainers  will  have  fewer  systems  that  they  must  repair. 

Strictly  controlling  the  introduction  of  new  parts  into  the  design  is  effective  if 
established  at  the  start.  For  example,  Electric  Boat  noted  that  USS  Seawolf  had  over 
100,000  unique  parts  that  required  separate  purchase  actions,  storage  control,  and 
consideration  for  spare  parts  support.  The  Virginia  Class  program  had  a  policy  that  new 
parts  could  only  be  introduced  into  the  design  with  the  approval  of  a  single  individual, 
and  the  result  was  a  limited  number  of  unique  parts.  For  the  Virginia  Class,  Electric  Boat 
built  a  standard,  approved  parts  library  inside  its  collaborative  PLM  system.  Of  the 
105,400  parts  available  for  review  from  the  USS  Seawolf  (SSN-21)  design,  Virginia’s 
team  reviewed  about  98,000  of  them  and  selected  about  15,000  as  USS  Virginia  standard 
parts.  The  final  design  will  have  fewer  than  one  fifth  the  unique  parts  compared  to  USS 
Seawolf.  This  parts  reduction  strategy  has  a  direct  effect  on  administrative  costs  for 
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purchasing  and  storage  for  ship  construction,  and  will  reduce  the  amount  of  spares 
required  for  life  cycle  support  (General  Dynamics  Electric  Boat,  2002). 

To  get  the  most  of  a  common  catalog,  the  engineers  must  know  what  is  in  it. 
Each  of  the  collaborative  PLM  suites  evaluated  contained  a  method  to  search  and  recall 
information  based  on  a  variety  of  parameters.  Because  all  designs  will  be  initiated  under 
one  roof  (the  NDO),  it  will  be  easy  to  ensure  the  processes  remain  consistent,  regardless 
of  platfonn.  This  means,  basically,  that  data  is  data  and  will  become  interchangeable. 
Yesterday,  the  task  may  have  been  designing  a  pump  for  LPD  17  and  today,  for  LCS. 
The  function  of  the  pump  did  not  change,  so  why  should  the  design?  The  constant  design 
exercises  will  not  only  keep  the  idea  bank  full  with  ready-to-go  designs,  but  it  will  also 
keep  the  engineers  up  to  date  with  what  has  already  been  done  before,  constantly 
updating  design,  making  improvements,  and  creating  the  new  standards.  This  helps  give 
a  reason  that  past  efforts  have  not  been  complete  successes.  A  second  disadvantage  of 
any  commonality  program  is  the  potential  to  limit  competitiveness,  as  only  those 
products  conforming  to  the  standard  are  eligible  for  consideration,  regardless  of  the 
quality  of  the  product.  A  technology,  such  as  collaborative  PLM,  capable  of  storing, 
sorting,  and  using  huge  amounts  of  data  is  only  half  of  the  solution.  It  must  be  paired 
with  a  healthy  organization  that  understands  not  only  which  data  is  available  for 
incorporation  into  the  design,  but  also  how  to  interact  with  a  database  such  as 
collaborative  PLM  efficiently  so  that  it  is  easier  to  find  current  design,  as  opposed  to 
simply  doing  it  over  again. 

C.  MANAGING  RISK  TO  IMPROVE  OUTCOMES 

1.  Private-Sector  Retire  Risk  Prior  to  Contract  Signing 

As  budgets  shrink,  decision-makers  will  have  to  determine  what  programs  are  to 
receive  the  reduced  funds.  However,  the  volatility  of  the  cost  estimates  is  one  thing  that 
gets  managers  called  before  Congress.  In  2009,  96  programs  evaluated  by  the  GAO  were 
a  cumulative  $296  billion  over  budget.  Overruns  of  this  magnitude  will  make  any 
planning  ineffective,  and  will  cripple  the  acquisition  programs  if  not  addressed  as  the 
funds  dry  up  (GAO,  2010). 
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Removing  programmatic  risk  as  early  as  possible  is  a  proven  method  to  reduce 
the  volatility  currently  plaguing  the  naval  acquisition  portfolio.  Analysis  provides  an 
opportunity  to  not  only  gain  a  full  understanding  of  the  potential  risks  associated  with  a 
particular  project,  but  also  to  determine  if  those  risks  can  be  mitigated  prior  to  bidding  on 
the  ship.  If  the  shipbuilder  fails  to  mitigate  the  risks,  it  could  encounter  problems  later  in 
the  construction  process  that  will  require  additional  unplanned  resources.  It  would  be 
difficult  for  shipbuilders  to  stay  competitive  with  extra  capacity  available;  thus,  these 
unplanned  resources  would  likely  be  pulled  from  other  projects,  potentially  cascading 
through  the  entire  organization,  delaying  multiple  ships,  and  damaging  the  organization’s 
reputation  and  ability  to  acquire  new  work.  Figure  18  shows  the  desired  process, 
emphasizing  early  risk  mitigation  in  commercial  shipbuilding  programs  (GAO,  2009b). 
While  the  naval  acquisition  community  doesn’t  have  the  same  luxury  of  deciding  to  pass 
on  a  particular  class  of  ships  if  it  appears  too  risky,  the  process  of  early  risk  mitigation 
still  offers  benefits,  leaving  a  program  more  capable  of  delivering  performance  on  cost 
and  schedule. 


More  risk 


Project  Initiation 


Contract  is  signed 
only  when  all  major 
risk  has  been  retired 


Construction 
begins  only  when  basic 
and  functional  design 
are  fully  complete 


Ship  delivery 


Pre-contract 

Cost  and  schedule  are  inviolate,  so  ( 
the  shipyard  works  with  ship  owner  ( 
to  retire  all  major  risk 

Ship  attributes  are  well  understood  I 
and  unchanging.  1 

New  technologies  are  evaluated  and  j 
dscarded  if  not  well  understood  | 

Commercial  ship  buyers  and 
shipbuilders  refuse  to  sign  contracts  1 
involving  immature  technologies. 

Price  and  delivery  date  set  and  firm,  i 
fixed  contracts  used.  | 

Uncertainty  is  limited  by  leveraging  1 
existing  designs  or  designing  based  1 
on  commonalty  with  reference 
ships. 


Design 

More  time  is  allotted  in  the  schedule 
if  a  dean  sheet  design  is  used. 

Basic  and  functional  design  are  both 
fully  complete  -  usually  in  the  form 
of  a  3D  CAD  model  -  prior  to 
starling  construction. 


Construction 

Emphasis  is  on  maximizing  yard 
throughput  and  minimizing  time 
spent  in  dry  dock. 

Because  of  backlog  of  ships, 
shipyard  has  business  imperative  to 
deliver  on  lime. 


Figure  18.  Commercial  Practices:  Risk  Minimized  Pre-Contract 

(From  GAO,  2009b) 
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The  commercial  sector  relies  on  several  strategies  to  ensure  that  risks  are 
minimized  as  early  as  possible.  One  option  is  to  reuse  an  existing  design,  rather  than 
requiring  a  new  design  be  created  from  scratch.  Using  an  existing  design  saves  on  the 
amount  of  design  work  that  must  be  done,  and  historical  data  provides  assurance  to  the 
customer  that  the  design  can  be  built  and  that  the  particular  shipyard  can  build  it  for  cost 
and  on  schedule.  This  approach  tailors  nicely  with  collaborative  PLM  because  all  the 
data  from  previous  designs  are  already  in  the  system,  so  efforts  can  be  spent  updating  and 
modernizing  the  design  to  meet  current  objectives. 

The  GAO  reported  that  Korean  shipyards  utilize  this  tactic  as  they  maintain 
several  standard  designs  for  different  classes  of  ships  and  allow  customers  to  select  and 
modify  a  design  as  necessary  (GAO,  2009b).  The  cruise  ship  industry  has  a  similar  tactic 
that  may  be  more  suited  for  defense  programs.  The  Royal  Caribbean’s  Freedom  Class 
drew  heavily  off  the  design  of  its  predecessor,  the  Voyager  Class.  Even  though  the 
Freedom  has  a  different  hull  and  is  47  feet  longer,  it  uses  the  propulsion  system,  power 
lines,  and  several  other  basic  features  designed  for  the  Voyager.  The  cruise  industry  also 
understands  that  the  ships  will  undergo  extensive  revitalization  and  designs  them 
accordingly.  These  revitalizations  have  been  as  intensive  as  cutting  the  Royal  Caribbean 
ship  Enchantment  of  the  Seas  in  half  to  add  a  new  middle  section  of  cabins,  but  they  are 
more  commonly  used  to  introduce  new  features  that  were  not  mature  enough  to  be 
included  in  the  initial  build.  An  example  would  be  hydro-dynamically  efficient  ducktails 
to  improve  fuel  efficiency  (GAO,  2009b).  It  is  easier  to  resist  the  urge  to  insert  immature 
technology  when  planned  modernizations  will  ensure  the  ships  will  remain  state  of  the 
art. 
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I  In  the  1 990s,  Royal  Caribbean  wanted  to  change  the  propulsion  system  on  its  cruise  ships  from  standard 
I  fixed  propellers  driven  by  propeller  shafts  to  a  rotating,  podded  propulsion  system  called  Azipod.  These 

I  pods  carry  the  propeller  and  motor  outside  of  the  ship  and  have  the  capability  to  rotate  360  degrees. 

I  allowing  for  the  ship  to  be  pulled  through  the  water  as  well  as  pushed.  This  technology,  developed  by  a 
I  company  called  ABB,  offered  the  potential  of  improved  fuel  efficiency  and  greatly  enhanced 
I  maneuverability — affording  Royal  Caribbean  the  ability  to  construct  significantly  larger  cruise  ships 
capable  of  accessing  major  ports.  At  the  time  Royal  Caribbean  wanted  to  move  from  conventional 
propulsion  to  Azipod.  the  technology  had  only  been  installed  on  smaller  ships,  including  tug  boats  and 
|  icebreakers.  Royal  Caribbean  approached  ABB  about  the  possibility  of  scaling  Azipod  up  to  the  size 
JH  reQu'recl  for  a  cruise  ship  and  brought  the  shipyard  it  planned  on  using  for  the  project  on  board.  The  three 
Pities  worked  together  to  extensively  prove  the  technology  and  built  close-to-scale  versions  of  Azipod 
before  Royal  Caribbean  and  the  shipbuilder  both  became  comfortable  enough  to  move  forward  with  the 
project.  Further,  despite  its  growing  confidence  in  Azipod.  Royal  Caribbean  decided  that  it  was  prudent  to 
^  maintain  some  redundancy  through  installation  of  fixed  pods  that  could  provide  propulsion  in  the  event 

that  the  new  Azipods  failed.  After  overcoming  some  initial  maintenance  issues,  the  Azipods  project  proved 
successful  for  Royal  Caribbean.  The  enhanced  maneuverability  offered  by  the  Azipods  enabled  the 
company  to  initiate  development  of  the  new  220.000-ton  Oasis  of  the  Seas,  which  is  currently  under  construction  and  planned  to  be  the  largest 
cruise  ship  ever  built. 

Figure  19.  Royal  Caribbean  Cruises  Ltd.  Employment  of  Azipod  Propulsion 

(From  GAO,  2009b) 

The  cost  and  schedule  volatility  experienced  in  DoD  programs  could  be 
significantly  reduced  if  we  had  the  same  discipline  regarding  technology  insertion  as 
commercial  firms.  By  discipline  I  mean  that  new  technology  would  have  to  undergo 
modeling,  testing,  and  simulations,  to  prove  that  it  offers  significant  benefits  to 
performance,  or  operational,  and  maintenance  costs,  before  it  would  be  included  in 
designs. 


Figure  19  is  the  result  of  a  case  study  conducted  by  the  GAO,  demonstrating  how 
Royal  Caribbean  worked  through  the  risks  of  integrating  new  azipods  into  its  design 
(GAO,  2009b).  A  collaborative  PLM  suite  has  several  features  that  help  the  designers 
ensure  that  the  appropriate  level  of  risk  is  communicated  about  particular  components. 
For  instance,  particular  components  in  the  3D  model  can  be  color  coded  to  ensure  that 
high-risk  items  are  highly  visible.  Figure  20  shows  how  documents  and  data  can  be 
integrated  directly  into  the  model.  For  instance,  if  the  designer  saw  the  azipods  were 
color  coded  red,  they  could  click  on  the  component  and  bring  up  amplifying  data  such  as 
the  mitigation  plan  and  schedule,  the  testing  schedule,  or  any  other  data  necessary  to 
communicate  the  situation  of  that  particular  component.  The  designer  could  also  attach  a 
question  directly  to  the  component  that  would  be  answered  by  the  particular  point  of 
contact  for  that  component.  By  integrating  all  the  applicable  data  into  the  3D  model,  it 
helps  ensure  warnings  or  red  flags  are  not  overlooked  because  they  are  spread  out 
through  a  series  of  emails,  reports,  etc.  (R.  Langmead,  personal  communication,  April  4, 
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2010).  If  the  technology  cannot  be  matured  to  a  point  where  both  the  buyer  and  the 
builder  are  confident  that  it  will  perform  as  expected  and  not  delay  delivery,  then  it  will 
be  discarded  from  consideration  for  the  sake  of  program  success. 
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Figure  20.  Information  Can  Be  Imbedded  Directly  into  3D  Model 

(From  Murphy,  1997) 


2.  Navy  Shipbuilding  Programs  Don’t  Prioritize  the  Early  Mitigation  of 
Risk 

The  Navy  approaches  technology  development  differently  than  the  commercial 
approach  described  in  the  previous  section.  To  ensure  that  our  sailors  always  have  the 
advantage  in  a  fight,  the  Navy  needs  to  deliver  ships  that  have  outpaced  and  overmatched 
all  future  threats.  To  gain  this  advantage,  naval  acquisition  programs  are  generally  not 
restricted  to  proven  technologies.  Instead,  they  invest  considerable  resources  developing 
and  integrating  cutting  edge  technologies  that  can  meet  mission  requirements.  Unlike 
commercial  shipbuilding  counterparts,  the  Navy  has  been  willing  to  assume  the  risk  and 
enter  contracts  without  fully  functional  prototypes,  demonstrating  technologies  are 
mature  enough  to  validate  performance  expectations.  This  means  that  in  situations  where 
the  commercial  buyer  and  builder  have  full  understanding  of  the  requirements  to  design 
and  build  a  particular  ship  and  are  confident  enough  to  enter  into  a  firm  fixed-price 
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contract,  the  Navy  has  traditionally  used  a  cost-plus  contract,  assuming  the  majority  of 
the  risks.  The  GAO  was  able  to  capture  this  point  in  Figure  21,  which  highlights  the 
differences  between  the  assumptions  of  risk  in  naval  versus  commercial  shipbuilding 
programs  (GAO,  2009b). 
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Figure  21.  Navy  Practices:  Significant  Risks  Remain  Unresolved  at  Contract 
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(From  GAO,  2009b) 


Once  the  schedule  starts  slipping,  certain  risky  practices  are  employed  to  try  and 
recover  lost  time.  Examples  of  risky  practices  could  be  trying  to  design  and  develop 
technology  concurrently  and  starting  construction  before  achieving  a  stable  design.  For 
example,  when  designing  around  immature  technology  in  order  to  keep  the  design 
progressing  on  schedule,  shipbuilders  must  make  assumptions  about  systems  and 
equipment  when  actual  information  is  not  available,  for  instance  a  component’s  size, 
weight,  the  heat  generated  by  it,  its  vibration  profile,  and  so  on.  If  the  technology  does 
not  mature  according  to  those  assumptions,  then  the  shipbuilder  has  to  redesign  entire 
aspects  of  the  ship,  rework  portions  already  completed,  and  most  likely  conduct  that  work 
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in  an  inefficient  sequence.  These  types  of  practices  are  what  preclude  the  Navy  from 
finding  a  partner  willing  to  agree  to  a  fixed-price  contract. 

In  its  current  state,  the  Navy  does  not  allocate  sufficient  time  to  engage  all 
stakeholders  in  a  manner  similar  to  the  commercial  sector  (P.  Hudson,  personal 
communication,  April  6,  2010).  Instead,  there  is  a  race  to  understate  costs  and  risks  and 
become  a  program  of  record  by  rushing  decisions  on  requirements  and  specifications.  If 
the  LCS  program,  as  illustrated  in  Figure  22,  had  taken  the  opportunity  to  engage  in  open 
dialog  between  stakeholders,  it  could  have  alleviated  a  lot  of  its  headaches  by  realizing 
from  the  start  that  its  $220-million  and  two-year  build  time  was  unachievable  (GAO, 
2009b).  Inside  a  collaborative  PLM  environment,  all  of  the  stakeholders  are  integrated 
together  through  social  networking  tools,  thus  creating  a  culture  where  open 
communication  is  easier  and  problems  become  more  transparent,  helping  to  prevent 
designers  and  engineers  from  making  incorrect  assumptions  during  the  design. 


Mission:  LCS  is  designed  to  perform  mine  countermeasures,  anti-submarine  warfare,  and  surface 
warfare  missions  in  littoral  (coastal)  regions. 

Issues:  From  the  outset,  the  Navy  sought  to  concurrently  design  and  construct  two  lead  ships  in  the 
LCS  program  in  an  effort  to  rapidly  meet  pressing  mission  needs.  Implementation  of  the  new  Naval 
Vessel  Rules  (design  standards)  further  complicated  the  Navy’s  concurrent  design-build  strategy  for 
LCS.  According  to  Navy  officials,  these  rules  required  program  officials  to  redesign  major  elements  of 
each  LCS  design  to  meet  enhanced  survivability  requirements,  even  after  construction  had  begun  on 
the  first  ship.  While  these  changes  improved  the  robustness  of  the  LCS  designs,  they  contributed  to 
out-of-sequence  work  and  rework  on  the  lead  ships.  The  Navy  failed  to  fully  account  for  these  changes 
when  establishing  its  $220  million  cost  target  and  2-year  construction  cycle  for  the  lead  ships.  When 
design  standards  were  clarified  with  the  issuance  of  Naval  Vessel  Rules  and  major  equipment  deliveries 
were  delayed  (e.g.,  main  reduction  gears),  adjustments  to  the  schedule  were  not  made.  Instead,  with  the 
first  LCS,  the  Navy  and  the  shipbuilder  continued  to  focus  on  achieving  the  planned  schedule,  accepting 
the  higher  costs  associated  with  out-of-sequence  work  and  rework.  This  approach  enabled  the  Navy  to  achieve  its  planned  launch  date  for  the  first 
LCS,  but  required  it  to  sacrifice  its  desired  level  of  outfitting — a  practice  that  further  increased  costs  later  in  construction. 


Figure  22.  LCS  Program  Capsule 

(From  GAO,  2009b) 


The  Ford  aircraft  carrier  (CVN  78),  seen  in  Figure  23,  is  another  example 
showing  how  the  lack  of  early  risk  mitigation  could  jeopardize  the  success  of  a  program. 
One  of  the  foundational  technologies  on  CVN-78  is  the  electromagnetic  aircraft  launch 
system  (EMALS),  a  catapult  that  uses  an  electrically  generated  magnetic  field,  instead  of 
steam,  to  accelerate  aircraft  to  launch  speeds.  The  EMALS  offers  several  advantages 
over  steam,  including  improved  sortie  rate,  less  stress  on  the  airframes  due  to  more 
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controlled  acceleration,  and  a  reduced  demand  for  fresh  water.  It  also  weighs  less, 
requires  less  space,  requires  less  maintenance  and  manpower,  and  is  more  reliable.  The 
downside  is  that  it  is  an  immature  technology  that  has  not  been  proven  by  an  operational 
prototype.  Because  work  did  not  stop  to  wait  to  see  how  EMALS  would  evolve  if  the 
assumptions  needed  to  be  modified,  it  could  result  in  major  amounts  of  rework. 
Collaborative  PLM  would  have  given  the  design  teams  the  ability  to  create  a  mirror  of 
the  CVN-78  design  and  progress  one  with  EMALS  and  one  with  the  traditional  steam. 
This  would  have  eliminated  a  portion  of  the  risk:  if  EMALS  fails  and  a  plan  B  is  needed, 
then  an  alternative  to  EMALS  would  be  on  the  shelf,  ready  to  go. 


Mission:  The  Navy's  CVN  21  program  is  developing  a  new  class  of  nuclear-powered  aircraft  carriers 
that  will  replace  USS  Enterprise  and  the  Nimitz-class  as  the  centerpiece  of  the  carrier  strike  group.  The 
new  carriers  are  to  include  advanced  technologies  in  propulsion,  weapons  handling,  aircraft  launch  and 
recovery,  and  survivability  designed  to  improve  operational  efficiency  and  enable  higher  sortie  rates 
while  reducing  required  manpower. 

Issues:  CVN  21  technologies,  including  EMALS.  the  dual  band  radar,  and  the  advanced  arresting  gear, 
have  all  experienced  schedule  delays  that  could  disrupt  construction  of  the  lead  ship  in  the  Ford-class, 
CVN  78.  EMALS  was  initially  designed  and  tested  in  a  configuration  that  minimized  the  system’s  weight. 
However,  after  the  Navy  defined  the  ship’s  survivability  requirements,  the  system  was  reconfigured  and 
its  weight  increased  above  its  margin,  resulting  in  reallocation  of  weight  elsewhere  on  the  ship  and  the 
redesign  of  a  subsystem.  Further,  the  contractor  for  EMALS  designed  one  subsystem  component — the 
power  conversion  system — to  generic  shock  and  vibration  requirements  while  waiting  for  the  Navy's  final 
determination  of  shipboard  requirements.  At  present,  the  subsystem  may  need  to  be  reconfigured  during 
production  in  order  to  meet  final  requirements — an  outcome  the  contractor  attributes  to  delays  arising  from  limited  coordination  with  the  shipyard  on 
requirements  issues.  Dual  band  radar  testing  has  been  delayed  as  a  result  of  technical  difficulties  in  developing  the  volume  search  radar.  Upcoming 
land-based  tests  will  be  conducted  at  a  lower  voltage  than  needed  to  meet  requirements  and  without  the  radar’s  composite  shield.  Full  power  output 
will  not  be  tested  on  a  complete  system  until  2012,  and  carrier-specific  functionalities  will  be  demonstrated  shortly  before  shipyard  delivery  in 
2013 — an  approach  that  leaves  little  time  to  resolve  problems  ahead  of  ship  installation.  In  addition,  the  advanced  arresting  gear  has  encountered 
delays  resulting  from  difficulties  meeting  the  Navy’s  requirements  for  the  system.  Specifically,  the  Navy  and  the  contractor  disagreed  on  the 
necessary  format  of  design  drawings,  drawings  were  delivered  late,  and  changes  in  Navy  requirements  for  shock  and  vibration  led  to  a  redesign  of 
a  major  subsystem. 


Figure  23.  CVN-78  Program  Capsule 

(From  GAO,  2009b) 


The  AEGIS  project  is  an  example  of  how  the  Navy  has  successfully  reduced  the 
risks  of  a  new  program.  Deputy  Secretary  of  Defense  David  Packard  directed  a  number 
of  actions  when  the  contract  was  awarded,  including  the  completion  of  a  simplification 
effort  to  reduce  complexity  and  costs.  The  AEGIS  program  required  the  use  of 
engineering  development  models.  Engineering  development  models  are  versions  of  the 
system  that  are  used  to  demonstrate  the  system  performance.  Once  demonstrated,  a 
second  engineering  development  model  could  further  the  design  moving  on  to  the  next, 
more  complex  version.  This  testing  program  was  referred  to  as,  “Build  a  little,  Test  a 

little,  Learn  a  lot.”  And  was  based  on  incremental  testing  of  function  and  components  as 
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the  system  was  built.  Hood  argued,  that  the  escalation  of  functionality  and  complexity 
was  built  upon  a  solid  base  of  performance,  and  was  a  key  element  in  reducing 
integration  problems,  increasing  the  chances  of  success  (Hood,  2009). 

Technological  development  requires  a  different  skill  set  than  program 
management.  We  are  asking  too  much  of  our  managers  to  try  to  maintain  cost  and 
schedule  benchmarks  based  on  a  new  technology  that  does  not  exist  yet  (P.  Hudson, 
personal  communication,  April  6,  2010).  All  of  our  programs  would  be  better  served  by 
taking  a  lesson  from  the  commercial  sector;  leave  the  technology  development  in  the 
research  labs.  Instead,  we  should  produce  designs  based  on  proven  technologies  and  plan 
for  upgrades,  once  the  technology  becomes  available.  Until  this  happens,  collaborative 
PLM  offers  the  capability  to  ensure  that  the  data  is  organized  in  a  fashion  that  increases 
the  visibility  of  the  risk  so  the  appropriate  attention  can  be  assigned,  as  a  portion  of  the 
risk  can  be  mitigated  by  progressing  two  designs  simultaneously,  just  in  case  one  fails. 

D.  SMART  PRODUCTS  CAN  CLOSE  THE  DATA  LOOP 

Smart  products  are  products  that  can  sense  and  communicate  information  about 
their  condition  and  environment.  The  idea  is  that  infonnation  becomes  knowledge  on 
how  to  support  existing  products  or  create  new  and  better  ones.  Promise  is  an  innovative 
project  that  has  demonstrated  how  to  use  smart  products  to  build  on  the  capabilities  of 
collaborative  PLM,  offering  companies  a  new  business  model  and  new  ways  of  creating 
value  (Stark,  2010).  Most  of  the  systems  that  the  Navy  operates  already  offer  some 
degree  of  smart  functionality,  meaning  that  we  have  sensors  in  just  about  all  of  our 
equipment  to  monitor  operating  conditions  and  transmit  it  over  networks  to  operators  in, 
for  instance,  the  control  room  or  bridge.  However,  the  Promise  program  demonstrates 
that  there  are  other  potential  benefits,  and  smart  products  with  collaborative  PLM  can 
reform  the  acquisition  portfolio,  by  converting  a  constant  stream  of  data  directly  from  the 
products  into  knowledge  usable  by  the  designers. 
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1.  Promise  Project  Concept 

The  core  concept  of  Promise  (Figure  24)  is  that  information  captured  by  smart 
products  can  be  transformed  into  knowledge  that  can  be  used  to  better  support  existing 
products,  create  new  products,  as  well  as  service  value  (Kiritsis,  Moseng,  Rolstadas,  & 
Rostad,  2008).  One  of  the  greatest  weaknesses  in  the  current  product  lifecycle  is  the 
barrier  that  prevents  the  flow  of  information  between  phases.  For  instance,  once  a  product 
leaves,  their  area  designers  rarely  get  data  on  actual  product  use.  An  attempt  to  address 
this  weakness  is  the  practice  of  hiring  previous  operators  to  design  the  new  systems  or 
involving  current  operators  in  the  process  to  capitalize  on  the  experience  they  each  have. 
The  Promise  project  demonstrates  that  there  is  a  much  better  way  to  close  the  information 
loop. 


PLM  agent 
(reader  with  antenna) 


-Diagnosis 
•Decision  making 

Figure  24.  Promise  Concept 

(From  Kiritsis  et  ah,  2008) 

The  Promise  project  extends  existing  smart  product  and  collaborative  PLM 
technologies  by  using  product  embedded  information  devices  (PEIDs)  based  on  a 
combination  of  existing  technologies,  such  as  bar  code,  radio  frequency  identification 
(RFID)  transponders,  and  short-  and  long-range  wireless  communication  technologies. 
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Promise  technologies  are  being  tested  in  1 1  demonstrations  in  the  automotive,  railway, 
heavy  vehicle,  electronics,  and  white-goods  sectors  (Stark,  2010).  The  advantages  and 
improvements  identified  by  the  Promise  project  demonstrate  how  the  Navy  could 
leverage  these  efforts. 


Closing  the  information  loop  creates  benefits  for  many  participants  in  the  product 
lifecycle: 

•  Customers  get  better  products  and  services. 

•  Manufacturers  get  more  information  about  the  conditions  and  modes  of 
product  use  and  disposal. 

•  Service  engineers  get  up-to-date  infonnation  about  the  status  of  the 
product  and  its  parts. 

•  Product  developers  use  real-life  experience  with  previous  products  to 
improve  future  products,  reduce  over-engineering,  and  achieve  lifecycle 
quality  goals. 

•  Recyclers  get  complete  information  about  the  EOL  value  of  products, 
parts,  and  materials.  (Stark,  2010). 

New  services  and  improvements  made  possible  with  Promise  include 

•  Innovative  products  and  services  that  go  far  beyond  competitor  offerings  and 
are  difficult  for  less-skilled  competitors  to  copy. 

•  Improved  customer-relationship  management  based  on  up-to-date  real-life 
product  data. 

•  Simplified  product  authentication  and  enhancement  of  product  and  user 
security  and  safety. 

•  New  types  of  product  leasing  and  insurance  services. 

•  Improved  maintenance  and  service  at  reduced  cost.  (Stark,  2010) 


2.  Promise  Project  Demonstrations 

The  Promise  project  completed  11  demonstrations  proving  the  benefits  and 
capabilities  of  these  smart  technologies.  All  1 1  showed  unique  ways  that  smart  products 
could  improve  a  company’s  business  model.  A  summary  of  one  of  the  demonstrations 
from  the  Promise  final  report  as  well  as  a  hypothetical  naval  application  follow. 

a.  Predictive  Maintenance  for  Trucks 

The  overall  objective  of  this  demonstrator  is  to  support  the  maintenance  of 


a  fleet  of  cargo  carrying  semi  trucks,  optimizing  the  maintenance  plan  and  increasing  the 
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overall  availability  of  the  trucks.  The  fleet  of  trucks  worked  under  nonnal  conditions, 
installed  sensors,  and  collected  and  continuously  updated  operational  data.  The  data  was 
transmitted  via  a  wireless  GPS  link  to  a  ground  station,  where  the  data  was  stored  and 
processed  through  diagnostic  algorithms  to  develop  predictive  infonnation.  After 
analyzing  the  data,  the  ground  station  computer  sends  a  maintenance  schedule  to  each 
vehicle,  garage,  design  department,  production  department,  and  supplier  (Kiritsis  et  al., 
2008). 

(1)  Objectives.  The  overall  objective  of  the  demonstrator  is  to 
support  the  maintenance  of  a  fleet  of  trucks,  optimizing  the  maintenance  plan  and 
increasing  the  overall  availability  of  the  trucks.  Closing  the  infonnation  loop  for 
predictive  maintenance  will  improve  the  knowledge  of  the  customer,  as  well  as  the  actual 
use  profde  of  the  vehicle,  making  it  possible  to: 

•  Reduce  the  number  of  vehicle  stops  for  maintenance, 

•  Minimize  the  overall  lifecycle  costs  of  the  components, 

•  Avoid  component  breakdowns, 

•  Take  into  account  vehicle  availability  while  planning  maintenance  interventions, 

and 

•  Take  into  account  maintenance  crew  availability  for  perfonning  maintenance. 

(Kiritsis  et  al.,  2008) 

(2)  Naval  Application.  The  theory  behind  this  demonstration  is 
that  the  trends  in  perfonnance  can  offer  a  variety  of  benefits  throughout  the  lifecycle. 
The  Navy  already  understands  the  benefits  of  preventive  maintenance  and  has  a  detailed 
maintenance  schedule  that  is  followed  on  each  piece  of  equipment  it  owns.  However, 
these  schedules  are  developed  by  the  contractor  based  on  lab-testing  data.  Each  of  our 
ships  operates  in  a  different  manner  in  entirely  different  environments.  It  is  unreasonable 
to  expect  the  wear  of  a  piece  of  equipment  operating  in  the  blowing  sand  of  the  Persian 
Gulf  to  mimic  the  results  obtained  in  the  lab.  To  account  for  these  differences,  safety 
margins  are  built  into  the  schedule.  For  instance,  a  part  that  is  expected  to  fail  at  36 
months  will  be  replaced  at  30  months.  Using  smart  technologies  and  collaborative  PLM 
to  capture  the  data,  the  ships  will  get  a  maintenance  schedule  based  on  actual 
performance,  helping  eliminate  waste  associated  with  replacing  perfectly  good  parts,  just 
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because  of  what  month  it  is.  The  maintainers  will  have  a  tool  that  can  identify  other 
problems  based  on  a  particular  part  wearing  out  faster  on  one  ship  versus  another.  The 
suppliers  can  accurately  forecast  the  part  lifespan  and  increase  operational  availability  by 
decreasing  the  normal  downtime,  during  which  they  had  to  wait  for  a  part  to  fail  before 
they  could  order  a  replacement. 

A  second  naval  example  corrects  the  process  of  designers  basing 
decisions  on  the  sporadic  and  inaccurate  information  provided  from  the  operators.  Smart 
products  allow  the  designer  to  pull  actual  data  from  the  product.  For  instance,  if  a 
particular  pump  is  designed  to  move  200  gallons  per  minute,  from  the  operator’s 
perspective  the  pump  might  be  perfect,  as  it  has  always  performed  as  designed,  and  there 
have  been  no  issues.  But  the  data  directly  from  the  pump  may  tell  a  different  story.  For 
instance,  it  may  show  during  the  entire  operational  life  that  the  highest  quantity  ever 
moved  was  100  gallons  per  minute,  and  this  would  indicate  that  the  original  pump  was 
over-engineered.  Thus,  future  design  can  more  accurately  reflect  the  expected  operations. 

Designers  can  obtain  data  on  the  actual  mission  profile  to  assist  in 
developing  better  products.  They  can  also  eliminate  waste  by  noticing  that  a  particular 
part  has  been  over-  or  under-  engineered.  All  this  can  be  accomplished  automatically, 
inside  a  collaborative  PLM  environment,  eliminating  the  time  and  errors  typically 
associated  with  completing  the  tremendous  amount  of  paperwork  that  currently  is 
necessary  in  today’s  process. 

E.  GAINING  CONTROL  OVER  TOTAL  OWNERSHIP  COSTS 

1.  Commercial  Companies  Offer  a  Model  on  How  to  Address  TOC 

Select  commercial  companies  have  experienced  a  competitive  edge  by 
deliberately  managing  and  controlling  TOC  as  a  part  of  their  acquisition-development 
process.  They  strive  to  attain  knowledge  about  their  products  as  early  in  the 
developmental  process  as  possible,  they  make  sure  the  design  is  mature  and  stable  prior 
to  starting  production,  and  they  have  the  production  processes  under  control  before 
production  begins.  Companies  such  as  United  Airlines,  FedEx  Express,  and  Polar  Tanker 
strive  to  maintain  the  readiness  of  their  fleets  at  as  low  an  operational  cost  as  possible — a 
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strategy  to  increase  profits  and  gain  a  market  advantage.  As  customers,  they  rate 
operational  and  support  costs,  product  readiness,  procurement  costs,  and  performance 
requirements  equally.  For  example,  United  Airlines  penalizes  a  supplier  for  lost  revenue 
if  the  aircraft  fails  to  maintain  a  readiness  rate  of  98.5%.  Polar  Tanker  drove  trades 
during  design,  sometimes  increasing  development  costs  to  achieve  lower  operating  costs 
by  making  a  requirement  that  its  Endeavor  Class  tanker  operate  at  least  330  days  a  year  at 
a  reduced  operating  cost  per  tanker.  FedEx  Express  required  the  design  of  its  new 
delivery  truck  to  be  able  to  operate  for  300,000  miles  at  a  specific  cost  per  mile  (GAO, 
2003b). 


b.  Polar  Tanker 


Figure  25.  Polar  Tanker 

(From  GAO,  2003b) 

Polar  Tanker  (see  Figure  25)  is  a  commercial  oil-transportation  company 
that  designed  a  new  tanker  for  its  run  between  Puget  Sound  and  Prince  William  Sound. 
The  company  had  two  requirements  it  deemed  critical  to  its  ability  to  reduce  the  cost  of 
delivering  oil:  (1)  it  required  less  expensive  operations  and  maintenance  over  a  30-year 
lifecycle,  thus  increasing  the  industry  standard  lifecycle  by  10  years;  and  (2)  the  tanker 
had  to  be  operationally  available  for  at  least  330  days  per  year  (GAO,  2003b). 

To  design  their  new  double-hulled  tankers,  the  procurement  team  relied  on 
the  knowledge  and  experience  of  its  maintenance  engineers,  along  with  archived 
maintenance  data  from  other  Alaskan  operations.  The  design  team  was  able  to  make 
tradeoffs  that  reflected  the  low  maintenance,  high  availability  strategy  for  this  tanker. 
For  instance,  the  previous  data  collected  revealed  ballast-tank  maintenance  as  one  of  the 
most  significant  cost  maintenance  burdens.  Based  on  this  knowledge,  the  Polar 
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shipbuilder  made  the  decision  to  use  the  most  expensive  epoxy  coatings  and  specialized 
paints  to  protect  the  tanks  from  corrosion.  This  is  an  example  of  how  integrating  the 
knowledge  gained  during  sustainment  can  benefit  the  design.  Integrating  knowledge 
throughout  the  lifecycle  is  the  cornerstone  of  collaborative  PLM  applications. 

Another  lesson  to  take  away  from  this  program  was  its  use  of  the 
modeling  and  simulation  tools  to  improve  the  design.  Polar  Tanker  assessed  the  fatigue 
cracking  in  the  hulls  of  its  fielded  fleet  and  used  this  data  in  modeling  tools  to  detennine 
what  structural  changes  would  result  in  the  optimal  structure.  These  are  just  two 
examples  of  Polar  Tanker  trading  higher  design  costs  (about  $25  million)  for  lower  TOC 
(GAO,  2003b). 


c.  United  Airlines/Boeing 


Figure  26.  United  Airlines 

(From  GAO,  2003b) 

United  Airlines  (see  Figure  26)  established  strict  requirements  regarding 
readiness  and  operation  cost  for  the  new  Boeing  777,  ensuring  reliability  was  an 
important  design  element.  United  specified  that  the  new  plane  had  to  be  capable  of  flying 
extended  ranges  from  any  U.S.  airport,  that  it  not  exceed  current  operational  and  supports 
costs,  and  that  it  be  available  at  the  gate  within  15  minutes  of  departure  98.5%  of  the 
time.  If  Boeing  fell  short,  they  agreed  to  compensate  United  for  lost  revenue.  Reliability 
was  highly  valued  by  United  in  its  new  plane  (GAO,  2003b). 

Boeing  approached  the  design  for  its  new  aircraft,  just  as  Polar  approached 
the  tanker,  by  merging  the  experience  of  experts  and  the  operations  and  maintenance 
histories  of  its  current  planes.  They  assigned  engineers  to  shadow  the  planes’ 


99 


maintenance  crews  to  collect  data.  The  data  history  led  them  to  the  root  causes  behind 
maintenance  failures,  and  the  experienced  experts  gave  insight  into  how  to  resolve  the 
issues.  The  result  was  a  team  focused  on  delivering  the  strategic  value  held  by  its 
customer:  an  easy-to-repair  aircraft  (GAO,  2003b). 

The  previous  section  introduced  smart  products,  which  can  communicate 
directly  with  the  collaborative  PLM  systems,  preventing  the  need  for  engineers  to  shadow 
the  design  team.  The  products  themselves  will  create  the  data  history,  and  depending 
how  automated  the  analysis  tools  are,  collaborative  PLM  could  use  the  data  to  perform 
analysis  and  recommend  a  solution  for  engineer  approval. 

d.  FedEx  Express 


Figure  27.  FedEx  Express 


(From  GAO,  2003b) 

The  FedEx  Express’s  mission  (see  Figure  27)  is  to  provide  global  air  and 
ground  transportation  of  high-priority  goods  and  documents  that  require  rapid,  time- 
certain  delivery.  It  is  easy  to  understand  why  high  availability,  high  reliability,  and  low 
operating  cost  would  be  very  valuable  in  the  fleet  of  vehicles  operated  to  accomplish  this 
mission.  When  designing  the  new  fleet  of  trucks,  FedEx,  just  as  the  other  examples, 
created  an  integrated  team  consisting  of  design  engineers,  suppliers,  a  logistics  expert, 
maintainers,  as  well  as  their  own  representatives.  The  result  was  a  new  700  cubic-foot 
truck  that  averages  70,000  miles  between  breakdowns,  while  operating  below  FedEx’s 
established  cost-per-mile  threshold  (GAO,  2003b).  FedEx  created  manually  an  integrated 
team  that  spanned  the  entire  lifecycle  to  ensure  that  one  phase  or  feature  was  not 
maximized  at  the  expense  of  another.  This  is  the  same  approach  collaborative  PLM 
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takes  as  data  and  knowledge  are  integrated  across  the  lifecycle.  Social  networking  tools 
built  into  the  collaborative  PLM  system  can  create  virtual  teams  to  produce  an  integrated 
design,  without  physically  dislocating  the  team  members  from  their  primary  functions. 

2.  Use  of  Feedback  to  Better  Understand  Customers’  Needs 

The  examples  from  Polar,  Boeing  and  FedEx  show  that  leading  commercial 
companies  consider  it  essential  to  collect  and  analyze  data  from  fielded  systems. 
Tracking  the  actual  operating  cost,  reliability  of  parts,  and  readiness  of  systems  offers  the 
ability  to  validate  the  processes  and  estimates  created  during  design.  A  collaborative 
process  between  the  customer  and  developer  seems  to  be  able  to  positively  influence  the 
design  of  new  products  by  drawing  extensively  from  past  and  current  operations.  Boeing 
has  personnel  residing  with  the  airlines  to  assist  as  problems  arise.  They  also  feed  all 
relevant  information  back  to  the  designers  to  improve  the  next  product. 

United  conducts  a  quarterly  meeting  with  representatives  from  across  the  lifecycle 
to  discuss  open  issues  with  operational  aircraft  and  develop  short-  and  long-term 
solutions.  United  also  monitors  flight  movements  on  a  computer  system  that  records 
each  aircraft  by  tail  number.  This  monitoring  is  much  more  than  a  record  of  the 
maintenance  history  of  each  aircraft.  It  can  report  problems  requiring  corrective  actions 
on  a  current  flight  so  that  ground  crews  can  be  prepared  upon  landing.  It  tracks  statistics 
and  operational  parameters,  and  recommends  preventive  maintenance  based  on  the  actual 
performance  instead  of  an  estimated  calendar  approach.  Completing  this  preventive 
maintenance  not  only  decreases  the  probability  of  a  catastrophic  failure,  but  also  offers 
the  ability  to  schedule  the  maintenance  to  be  completed  at  a  time  and  location  that  is  both 
convenient  and  cost  effective,  for  instance,  at  the  maintenance  hub  rather  than  a  remote 
field  that  lacks  the  necessary  mechanics,  parts,  and  tools. 

This  data  has  several  useful  applications  for  Boeing:  it  lets  them  know  how  it  can 
improve  future  iterations  of  the  product,  develop  better  preventive  maintenance 
schedules,  provide  better  estimates  of  the  operating  and  support  costs,  and  refine 
reliability  requirements  for  future  products  (GAO,  2003b).  All  of  these  are  examples  of 
possibilities,  once  our  organization  is  operating  inside  a  collaborative  PLM  environment. 


101 


The  Navy  shipbuilding  acquisition  community  could  apply  collaborative  PLM  in 
a  similar  fashion  with  similar  results.  The  Navy  could  use  collaborative  PLM  to  capture 
actual  data  during  the  operation  and  sustainment  phases  as  a  method  to  improve  the 
knowledge  available  to  designers  during  the  design  phase.  Analysis  of  system  failures  or 
maintenance  data,  or  sailor  inputs  could  be  used  to  improve  the  design,  or  justify  higher 
acquisition  costs  to  purchase  systems  with  reduced  TOC. 

3.  TOC  Hard  to  Control  in  Current  Linear  Acquisition  Strategy 

The  current  DoD  strategy  employs  a  linear  approach  to  setting  requirements, 
developing,  and  fielding  a  system  (Figure  28)  (GAO,  2003b).  Three  key  groups  are 
involved  during  this  process.  First,  there  is  a  warfighter  service  based  requirements 
community  that  establishes  what  the  requirements  will  be  for  the  new  system.  Second, 
there  are  acquisition  organizations  tasked  to  design  and  produce  a  product  to  meet  the 
established  requirements.  During  this  phase,  the  majority  of  effort  is  spent  on  developing 
revolutionary  performance  technologies  while  keeping  acquisition  costs  as  low  as 
possible.  Finally,  once  the  product  is  delivered,  it  is  turned  over  to  the  warfighter  for 
operations  and  maintenance.  One  of  the  problems  with  this  current  process  is  that  there  is 
not  much  communication  between  the  three  groups.  Decisions  made  when  establishing 
the  requirements  have  a  dramatic  effect  on  the  overall  system.  Tradeoffs  made  during 
design  usually  are  to  maximize  the  performance  capabilities  identified  in  the 
requirements.  By  the  time  the  operators  and  maintainers  are  brought  into  process  they 
can  have  very  little  influence  and  have  no  alternative  but  to  pay  the  support  bills  and  try 
and  figure  out  workarounds  to  maintain  readiness  (GAO,  2003b). 
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Requirements 


Mission  deficiency  or 
need  established  by  the 
war  fighting  community. 

Operational  requirements 
formulated  by  the  war 
fighters'  representative. 

Operational  requirements 
based  on  accomplishing 
performance  objectives 
(range,  lethality,  mobility). 


Product 

development 


Performance  requirements 
are  translated  into  product 
specifications. 

Life  cycle  costs  estimate 
prepared. 

Needed  technologies  for 
meeting  operational 
performance  are  established. 

Contractor  responsible  for 
the  final  design  and 
production  is  selected. 

Design  is  matured  and  the 
production  processes 
established. 


Operations 


War  fighter  uses  the 
equipment  in  an 
operational  environment. 

War  fighter  (operational 
unit)  maintains  product. 

Operational  units  collect 
data  on  frequency  of 
repair. 

Operational  units  order 
and  use  spare  parts, 
consume  fuel,  support 
software. 


Figure  28.  DoD  Linear  Acquisition  Process 

(From  GAO,  2003b) 


4.  How  the  Navy  Can  Reduce  TOC 

The  DoD  has  similar  policy  goals  as  the  commercial  firm’s  best  practices,  and  the 
DoD  desires  to  deliver  products  that  will  not  only  meet  performance  requirements,  but 
also  do  so  at  the  lowest  possible  cost  to  build  and  operate.  Where  DoD  and  commercial 
firms  diverge  is  the  manner  in  which  each  implements  these  policy  goals.  The  private 
sector  operates  in  an  integrated,  collaborative  manner  from  requirement  definition 
through  design,  production,  operations,  and  support.  The  current  DoD  process 
encompasses  several  separate  organizations  with  different  objectives  and  little 
communication  between  them.  For  instance,  Naval  Shipyards  are  responsible  for 
conducting  maintenance  on  aircraft  carriers.  A  shipyard  has  a  knowledge  base  built  on 
seeing  components  that  have  failed,  an  understanding  why  they  fail  and  knowing  how 
they  must  be  repaired,  this  would  be  valuable  knowledge  for  ship  designers. 


While  both  understand  the  integrated  lifecycle,  commercial  firms  have  made  TOC 
a  priority  from  the  outset.  Until  very  recently,  the  DoD  has  been  focused  mainly  on 
technical  performance.  Several  possible  reasons  exist  for  this  behavior.  Responsibility  for 
TOC  is  spread  across  many  organizations,  and,  as  a  result,  no  one  is  held  accountable. 
The  metric  used  to  justify  killing  a  program  is  acquisition  costs,  so  managers  will  do 
anything  necessary  to  keep  that  as  low  as  possible.  The  private  firms  discussed  earlier 
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(United,  Polar  Tanker,  and  FedEx  Express)  must  manage  TOC  to  remain  profitable  to 
survive.  The  DoD  does  not  have  the  same  incentive.  Table  7  shows  a  GAO  comparison 
of  practices  between  commercial  firms  and  the  DoD.  If  more  operation  and  maintenance 
money  is  needed,  the  next  budget  request  simply  requests  the  additional  funds  to  keep  the 
systems  online  (GAO,  2003b). 


Table  7.  DoD  and  Commercial  Practices  for  Controlling  Operating  and 

Support  Costs 

(From  GAO,  2003b) 


Commercial  prevailing  practice 

DOD  prevailing  practice 

Practices  used  to  set  initial  product  requirements 

Operating  and  support  cost  goals  as  a  key  requirement. 

Operating  and  support  cost  goals  are  not  established  as  key 
parameters. 

Readiness  a  key  requirement. 

Readiness  is  not  a  key  parameter. 

Trade  performance  tor  reduced  operating  and  support  costs,  it 
appropriate:  sometimes  results  in  increased  costs. 

Technical  performance  is  sometimes  traded  using  cost  as  an 
Independent  variable,  but  cost  is  usually  production  cost  or 
development  cost,  and  the  trades  occur  durlnq  the  deslqn  phase. 

Direct  relationship  during  requirements-setting  between  the  user 
and  the  product  developer. 

User  and  product  developer  separated  by  user  representative  and 
government  program  office. 

Practices  used  during  product  development 

Provide  detailed  operating  and  support  cost  estimates  early  In 
product  development. 

Operating  and  suppon  cost  estimates  not  required  until  product 
development  launch. 

User  and  developer  locus  on  ways  to  reduce  product  pans  and 
standardize  pans  across  product  lines. 

Product  developer  has  responsibility  ol  focusing  on  ways  to 
reduce  parts  counts  or  use  standardized  parts  with  little  Input  from 
the  user  (operators  or  maintained). 

Use  open  systems  architecture  approach  to  Improve  the  cost 
effectiveness  and  installation  efficiency  of  future  upgrades  to  the 
product. 

Open  systems  approach  Is  mandated  but  Implementation  Is 
limited. 

Set  realistic  reliability  growth  goals  for  the  product 

Reliability  goals  set.  but  they  are  tradable  or  not  met. 

Conduct  reliability  testing  early. 

Reliability  testing  sporadically  performed. 

Practices  used  during  operations 

Collect  and  analyze  operations  and  suppon  data. 

Data  is  often  incomplete  or  unreliable. 

Manage  operations  and  support  costs  to  targets. 

Do  not  manage  to  operations  and  support  targets. 

Identify  areas  for  continuous  improvement. 

Lack  of  complete  and  reliable  data  makes  identifying  areas  for 
Improvement  difficult:  some  areas  that  are  identified  are  not 
funded  tor  Improvement. 

Feedback  to  developer  on  product  pertormance. 

Limited  feedback  to  the  developer.  The  maintainer  does  not  have 
a  direct  relationship  with  the  product  developer. 

a.  Change  the  Requirements  to  More  Specifically  Address  TOC 

The  GAO  cited  the  lack  of  accountability  and  responsibility  as  one  of  the 

primary  reasons  for  the  out  of  control  TOC  (GAO,  2003b).  Cited  in  a  previous 

recommendation,  the  NDO  should  be  held  accountable  for  the  quality  of  design,  as  TOC 

falls  under  his  or  her  responsibility.  To  evaluate  the  completeness  of  the  design,  the 

NDO  should  use  a  tool  such  as  the  LEAN  design  scorecard  spider  charts  from  Chapter 

IV. D.  This  change  should  help  ensure  that  the  DoD  and  the  Navy  understand  the  total 

picture  and  do  not  get  too  focused  on  a  particular  aspect,  such  as  perfonnance,  basically 
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making  the  Navy  a  smart  buyer.  The  Navy  must  also  use  the  data  collected  by 
collaborative  PLM  to  develop  other  predictive  metrics.  For  instance,  do  90%  of  drawings 
released  by  a  particular  milestone  demonstrate  design  stability  and  correctly  forecast  a 
program’s  probability  for  success? 

b.  Use  Evolutionary  as  Opposed  to  Revolutionary  Technology 

In  several  different  sections,  the  characteristic  of  commercial  firms 
eliminating  immature  technologies  from  consideration  has  been  touted  as  a  major 
contributor  to  their  success.  While  collaborative  PLM  technologies  do  not  necessarily 
help  with  the  physical  technology  maturity,  they  can  play  a  dramatic  role  in  the  execution 
of  evolutionary  acquisition.  Figure  29  is  a  graphic  from  a  GAO  report  on  the  F-22 
program.  It  illustrates  the  difference  between  the  two  approaches  (GAO,  2003a). 
Revolutionary  development  would  be  a  program  that  attempts  to  develop  immature 
technology  in  the  program.  In  the  GAO’s  example,  the  warfighter  had  a  requirement  for 
a  new  aircraft  but  had  to  wait  15  years  before  anything  was  delivered.  All  too  often,  the 
product  delivered  has  morphed  and  fails  to  satisfy  the  original  need  or  the  need  has 
changed  during  the  multiple  years  of  development. 

The  preferred  approach  is  evolutionary  product  development,  in  which  the 
requirements  are  met  over  several  generations  of  the  product.  In  the  GAO  example,  the 
first  generation  incorporates  the  needs  of  the  warfighter  and  the  available  technology 
from  the  research  labs.  The  warfighter  is  delivered  the  first  generation  platform  at  the 
five-year  point.  This  is  when  a  collaborative  PLM  can  offer  substantial  benefits  to  the 
process.  Once  the  warfighter  has  the  first  generation,  they  can  begin  to  offer  feedback  to 
the  designers  who  are  working  on  the  second  generation.  Feedback  could  be  likes, 
dislikes,  correcting  misinterpretations  of  the  requirements,  changes  to  the  need,  or  others. 
The  smart  products  themselves  are  communicating  with  the  designer  about  how  they  are 
performing  or  leading  to  improvements.  Additionally,  the  research  labs  may  have  new 
technology  that  is  now  mature  enough  for  integration  into  the  second-generation 
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platform.  This  process  repeats,  and  each  successive  generation  of  product  evolves  into 
exactly  what  the  warfighter  needs,  while  never  accepting  undue  risk  from  immature 
technologies. 
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Figure  29.  Evolutionary  Versus  Revolutionary  Development  Comparison 

(From  GAO,  2003a) 


Virginia  class  submarine  is  an  example  of  a  design  with  planned 
technology  insertion  over  the  life  of  the  ship.  For  example,  the  structurally  integrated 
enclosures  are  designed  with  shockproof  supports  and  necessary  services  to  allow  for 
change  out  of  COTS  electronic  units;  the  universal  modular  masts  can  easily  accept  new 
sensors  in  the  sail;  and  the  baseline  ship  design  has  a  high  reserve  buoyancy  to 
accommodate  future  weight  growth.  In  addition,  the  modular  construction  method  used 
on  USS  Virginia  facilitates  technology  insertion,  since  equipment  can  be  removed  and 
replaced  as  individual  packages  (General  Dynamics  Electric  Boat,  2002). 

Electric  Boat  continues  to  plan  upgrades  to  the  Virginia  class  to  reach 

visions  captured  in  the  Submarine  Futures  Studies  Group  report  of  July  2000.  The  Navy 

has  proposed  an  upgrade  path  to  reach  the  2020  vision  with  specific  upgrades  proposed 

for  later  ships  of  the  class  (see  Figure  30).  For  example,  technologies  that  have  almost 
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reached  a  level  of  maturity  that  eliminate  the  risk  that  prohibited  prior  insertion  include: 
an  advanced  sail,  improved  payloads  and  sensors,  and  a  large-aperture  conformal  array. 
By  2020,  the  submarine  would  be  all-electric  with  fully  modular  payloads,  external 
weapons,  a  “smart  skin,”  high-rate  communications  at  depth  and  speed,  and  increased 
automation  (General  Dynamics  Electric  Boat,  2002).  The  Virginia  class  program  has 
been  designed  inside  a  collaborative  PLM  application,  making  the  technology  insertion 
easier  as  well  as  maintaining  several  configurations  of  the  class  of  ships  to  reflect  the  as 
designed,  as  constructed,  and  as  maintained  of  each  hull. 
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Figure  30.  Virginia  Class  Program  Planned  Technology  Insertion 

(From  General  Dynamics  Electric  Boat,  2002) 
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c.  Close  the  Feedback  Loop 

While  discussing  smart  products  in  the  section  “d.  Smart  Products  Can 
Close  the  Data  Loop,”  some  of  the  benefits  of  closing  the  information  loop  were 
explored.  Having  good  communications  between  each  phase  of  the  lifecycle  will  also 
help  control  TOC,  and  the  tools  to  foster  solid  communications  are  built  into  every 
collaborative  PLM.  Each  collaborative  PLM  platform  is  different,  but  they  all  deliver 
similar  capabilities.  Some  of  the  various  options  are  standard  email  points  of  contact 
built  into  the  design  files.  For  instance,  if  a  sailor  has  a  question  about  troubleshooting  a 
particular  component,  he  can  access  the  3D  model,  click  on  the  particular  part,  and  access 
any  point  of  contact  built  into  the  system,  from  designers  to  maintainers  to  an  engineer  or 
supplier.  There  are  more  advanced  options,  such  as  video  collaboration,  in  which  several 
people  can  chat  while  working  together  in  the  system.  Some  of  the  platforms  are  even 
developing  Facebook-like  social-networking  capabilities  that  allow  people  from 
specialized  areas  to  congregate  and  troubleshoot.  The  section  on  smart  products 
demonstrated  how  communication  is  not  limited  to  people,  but  the  products  themselves 
can  communicate,  inputting  knowledge  into  the  system  that  can  be  used  to  create 
improved  systems. 

F.  DESIGN  MATURITY 

1.  Design  Stability  of  the  Private  Sector 

Commercial  shipbuilding  typically  defines  a  design  as  stable  when  both  the  basic 
and  functional  designs  are  complete  (see  Table  8).  Until  this  stability  is  achieved,  they 
will  not  move  into  the  construction  phase.  Usually  the  product  is  a  complete  3D  product 
model,  demonstrating  a  clear  understanding  of  both  the  structure,  as  well  as  every  system 
and  how  those  systems  integrate  into  the  building  blocks  of  the  ship  (GAO,  2008a). 
Integrating  suppliers  into  the  process  is  very  important  to  design  stability,  as  they  not 
only  provide  a  complete  set  of  data  for  their  respective  systems,  but  also  are  the  experts 
in  their  fields  and  can  offer  valuable  insight  to  the  integration  into  the  total  ship. 
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Table  8. 


Description  of  Design  Phases 


(After  GAO,  2003b) 


Design  Phase 

Tasks  involved  and  parties  responsible 

Basic  design 

•  Fix  ship  steel  structure  and  set  hydrodynamics 

•  Design  safety  systems  and  get  approvals  from  applicable 
authorities 

•  Route  all  major  distributive  systems,  including  electricity,  water, 
and  other  utilities 

•  Ensure  that  the  ship  will  meet  the  performance  specification 

•  Complete  (shipbuilder)  and  review  (buyer) 

Functional 

design 

•  Provide  further  iteration  of  the  basic  design;  generally  equates  to 

3D  modeling 

•  Provide  information  on  exact  position  of  piping  and  other 
outfitting  in  each  block 

•  Complete  (shipbuilder)  and  review  (buyer) 

Bringing  the  vendors  on  board  and  not  relying  on  immature  technology  are  the 
best  ways  to  quickly  progress  the  design  and  lock  in  system  requirements  such  as  power, 
water,  and  other  utilities.  The  ability  to  gain  this  high  level  of  knowledge  early  reduces 
the  possibility  of  very  costly  design  changes  after  spaces  have  been  closed  out. 

During  the  LPD-17  program  Avondale  Industries,  Bath  Iron  Works,  Ingalls 
Shipbuilding,  National  Steel  and  Shipbuilding,  and  Newport  News  Shipbuilding  were 
contracted  to  provide  technical  services  during  concept  design.  These  shipyards  provided 
significant  inputs  on  subjects  such  as  metrication,  less  reliance  on  military  specifications 
and  standards,  corrosion  control,  materials,  and  producibility.  Nevertheless,  Keane, 
Mclntire,  et  al.  (2009)  argue  that  a  greater  investment  at  this  stage  of  design  could  have 
paid  big  dividends.  However,  since  this  level  of  involvement  was  not  factored  into  the 
initial  planning  for  the  program  it  was  not  adequately  funded  (p.  29). 

Involving  the  shipbuilder  in  the  early  design  allows  for  the  selected  vendors  to  be 
brought  into  the  design  process  much  earlier.  During  the  detail  design,  the  design  team 
benefits  greatly  from  early  access  to  the  vendor  furnished  information.  For  example,  for 
communication  between  electric  plant  devices  the  vendor  selected  by  the  shipbuilder  for 
LPD-17  Class  power  distribution  management  used  a  proprietary  Local  Area  Network 
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(LAN)  that  was  very  difficult  to  integrate.  This  LAN  was  not  addressed  in  the 
shipbuilding  specifications  because  it  was  not  anticipated;  if  it  had,  an  effort  would  have 
been  made  to  either  avoid  its  use  or,  make  the  necessary  accommodations  (Keane, 
Mclntire,  et  ah,  2009).  Having  to  constantly  go  back  and  fix  seemingly  harmless  changes 
wreaks  havoc  on  a  schedule,  with  cascading  effects  throughout  the  design. 

The  previous  sections  have  discussed  the  design  team’s  advantages  by  working 
with  the  buyers  and  the  vendors.  They  must  also  work  with  members  of  their  own  yard  to 
ensure  that  the  design  is  highly  producible.  This  producibility  concept  is  achieved  when 
the  design  is  successfully  matched  to  the  capabilities  and  production  techniques  of  the 
particular  shipyard,  so  the  ship  can  be  efficiently  constructed.  Activities  associated  with 
design  for  producibility  could  be  collaboration  between  the  construction  and  design 
teams  or  using  common  parts,  components,  and  processes  that  support  multiple  ships,  in 
order  to  take  advantage  of  the  learning  curve  (GAO,  2010).  The  capabilities  of 
collaborative  PLM  technologies  have  assisted  commercial  companies  with  both  of  these 
activities  through  collaboration  capabilities,  as  well  as  improving  the  visibility  into  the 
design  to  help  identify  trouble  before  it  ever  becomes  critical. 

2.  Design  Volatility  of  the  Public  Sector 

The  lack  of  early  systems  engineering  and  risk  mitigation  has  led  to  the  volatility 
plaguing  Navy  programs.  Starting  construction  before  the  design  is  stable,  a  common 
occurrence  for  Navy  programs,  increases  the  probability  of  costly  out-of-sequence  work 
and  rework.  For  example,  maturing  a  particular  technology  concurrently  with  design  and 
construction  opens  the  possibility  to  a  considerable  amount  of  volatility  to  the  design 
process.  As  the  technology  matures,  the  initial  assumptions  about  size,  shape,  weight,  as 
well  as  energy  requirements  and  byproducts  may  change  significantly. 

For  example,  the  Seawolf  class  attack  submarine  (see  Figure  31)  relied  on  a  new 
computer-aided  detection,  classification,  and  tracking  radar,  the  AN/BSY-2,  to  complete 
its  mission  requirements.  The  design  progressed  with  a  space  and  weight  reserved  for  the 
system.  However,  the  system  did  not  mature  as  the  Navy  expected,  and  it  turned  out  to  be 
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bigger  and  heavier  than  expected.  This  caused  the  need  for  a  considerable  redesign  of  the 
submarine  and  ultimately  led  to  the  delivery  of  a  platform  45%  over  budget  (GAO, 
2009b). 


Mission:  The  Navy’s  SSN  21  nuclear-powered  submarines  are  designed  to  track  and  engage  enemy 
targets  with  greater  depth,  speed,  and  stealth  capabilities  than  predecessors. 

Issues:  The  timely  development  of  AN/BSY-2 — a  computer-aided  detection,  classification,  and  tracking 
combat  system — was  critical  to  the  submarine  meeting  its  mission  requirements.  Even  though  this 
technology  was  a  modified  successor  to  the  AN/BSY-1  system  found  on  earlier  Los  Angeles-class 
submarines,  the  technology  did  not  mature  as  quickly  as  the  Navy  expected.  Changes  to  the  AN/BSY-2 
system’s  design  caused  a  portion  of  the  submarine  to  be  redesigned  at  an  additional  cost.  The  Navy 
originally  provided  Newport  News  with  general  space  and  weight  information  for  the  AN/BSY-2  that  the 
shipyard  used  to  begin  designing  its  portion  of  the  Seawolf.  The  Navy  later  provided  the  shipyard  with 
more  specific  information  that  caused  considerable  redesign  of  the  submarine  and  increased  design 
costs,  according  to  Newport  News.  The  lead  submarine  ultimately  experienced  cost  growth  on  the  order 
of  45  percent  above  initial  budget  estimates. 


Figure  31.  SSN-21  Program  Capsule 

(From  GAO,  2009b) 


Each  new  design  is  in  response  to  a  new  mission  requirement  that  will  likely  use  a 
new  technology,  making  it  easier  to  start  a  design  from  scratch  rather  than  modify 
anything  already  in  existence.  The  Virginia  class  (SSN  774  class)  submarine  was  a 
positive  example  of  how  a  collaborative  PLM  application  offers  improved  capabilities, 
for  instance,  how  a  new  design  could  leverage  off  past  efforts  by  reusing  a  number  of 
components  and  systems  tested  on  previous  submarines. 


Figure  32.  Percentage  of  Work  Package  Issued,  Virginia  Versus  Seawolf 
(General  Dynamics  Electric  Boat,  2002) 
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Figure  32  shows  the  drawing  release  history  for  the  USS  Virginia  compared  with 
the  USS  Seawolf  The  x  =  0  point  is  the  construction-start  date  for  each  program,  October 
1989  for  Seawolf,  and  October  1998  for  Virginia.  The  date  of  this  chart  is  February  2002 
(the  vertical  line);  thus,  all  Virginia  data  to  the  right  of  x  =  +3.3  are  projections,  whereas 
all  Seawolf  data  are  actual.  Virginia  had  released  99.1%  of  all  drawings  by  February 
2002,  about  3.5  years  earlier  than  Seawolf 


Figure  33.  Mature  Virginia  (SSN-774)  Design  Results  in  Fewer  Changes  During 

Construction 

(From  General  Dynamics  Electric  Boat,  2002) 


The  Virginia  IPPD  team  and  process  created  a  more  mature  design  to  support 
construction.  Figure  33  shows  that  50%  of  the  Virginia  design  had  been  issued  prior  to 
construction  start,  compared  to  5.6%  for  USS  Seawolf  ( SSN  21)  and  1.6%  for  USS  Ohio 
(SSBN  726).  The  Electric  Boat  team  had  a  disciplined  strategy  to  keep  contracts  and 
requirements  stable,  and  Figure  34  shows  the  pay  off.  The  figure  shows  the  projection 
for  contract  changes  are  about  12%  of  Seawolfs  and  0.46%  of  Ohio’s  (General 
Dynamics  Electric  Boat,  2002). 
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Not  having  to  spend  time  designing  everything  from  scratch  was  a  contributing 
factor  to  the  ability  to  have  a  complete  3D  model  prior  to  construction  start.  This  model 
was  a  contributing  factor  to  the  small  number  of  design  change  orders  (GAO,  2009a). 
This  design  volatility  has  been  a  major  root  cause  behind  the  cost  escalation  in  Navy 
programs.  The  cost  escalation  is  the  byproduct  of  the  risk  that  was  never  removed  and 
precluded  the  use  of  more  advantageous  contract  vehicles,  such  as  firm-fixed  price. 
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VIII.  SUMMARY  OF  RECOMMENDATIONS  AND  CONCLUSIONS 


The  defense  acquisition  community  is  responsible  to  design,  build,  and  deliver 
some  of  the  most  technologically  advanced  machines  in  existence.  Since  2002,  Congress 
has  appropriated  over  $74.1  billion  for  the  construction  of  new  aircraft  carriers,  nuclear 
submarines,  surface  combatants,  and  amphibious  transport  ships  (GAO,  2009b). 
However,  a  2010  review  of  96  defense  acquisition  programs  showed  the  average  delivery 
rates  are  22  months  behind  schedule,  with  a  cumulative  cost  growth  that  exceeded  $296 
billion.  These  are  indications  that  the  acquisition  community  has  room  to  improve  the 
execution  of  its  programs.  Compounding  the  current  inefficient  use  of  funds  is  the  high 
probability  of  defense  budget  cuts.  Unless  budget  cuts  are  accompanied  by  a 
corresponding  cut  in  missions,  the  Navy  will  need  a  more  efficient  utilization  of  dollars 
to  fulfill  all  tasking.  This  leaves  a  small  window  of  opportunity  to  enact  reforms 
improving  the  health  and  solvency  of  the  defense  acquisition  portfolio. 

Sean  J.  Stackley  (. Prepared  Testimony,  2009),  Under  Secretary  of  the  Navy,  said: 

Inarguably  the  underlying  challenge,  the  pressing  requirement,  before  us 
today  in  shipbuilding  is  affordability. 

The  reality  is  that  there  is  no  single  fix  to  turn  around  this  trend,  but  rather 
a  large  number  of  initiatives,  practices,  and  standards  that  we  need  to 
attack  across  the  board. 

We  need  to  ensure  that  our  requirements  are  balanced  by  our  resources . 

The  key  here  is  to  inform  the  process  with  realistic  cost  estimates  and 
realistic  risk  assessments  at  the  front  end.  This  drives  the  difficult 
decisions  early,  where  there  are  true  choices,  and  true  opportunities. 

The  Navy  has  the  opportunity  to  fundamentally  transfonn  the  acquisition 
community  by  enacting  reforms  addressing  some  of  the  root  causes  behind  the  cost 
escalation  and  schedule  delays  during  procurement  and  by  making  conscious  decisions 
that  will  reduce  TOC.  The  Navy  can  make  more  efficient  use  of  the  appropriated  budget 
by  addressing  these  root  causes. 
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This  research  was  a  search  for  answers  to  the  following  two  research  questions: 

1 .  How  can  a  technology  such  as  collaborative  product  lifecycle  management  (PLM) 
be  used  to  improve  the  acquisition  process? 

2.  What  reforms  to  the  acquisition  process  are  possible,  complimenting  or 
supplementing  the  capabilities  provided  by  collaborative  PLM,  helping  ensure 
value  is  optimized  throughout  the  lifecycle  of  the  product? 

Collaborative  PLM  can  offer  the  acquisition  community  features  and  capabilities 
that  can  be  used  to  positively  reform  the  acquisition  process.  Being  able  to  record, 
organize,  then  leverage  the  tremendous  amount  of  data  generated  in  a  new  ship  design 
program  is  paramount  to  the  decision  makers  making  quality  choices  from  the  total 
lifecycle  perspective.  PLM  also  offers  the  ability  to  integrate  data  across  the  entire 
acquisition  portfolio,  a  feature  when  coupled  with  the  social  networking  capability  can 
eliminate  redundant  efforts  and  increase  the  reuse  and  commonality  between  programs. 

Answering  those  questions  led  to  the  reforms  recommended  throughout  the  paper 
and  reiterated  in  the  Summary  of  Recommendations  for  Action  section  below.  Together, 
they  show  a  path  that  the  acquisition  community  can  follow  to  improve  as  an 
organization  and  move  the  portfolio  of  programs  toward  solvency.  The  reforms  will 
affect  the  three  main  elements  of  the  community:  its  organization,  people,  infonnation, 
technology,  processes,  and  practices.  The  synergy  between  each  of  these  elements  means 
that  reforms  collectively  working  together  will  produce  a  result  not  obtainable  by  anyone 
acting  independently. 

A.  SUMMARY  OF  RECOMMENDATIONS  FOR  ACTION 

•  Invest  in  a  collaborative  PLM  suite  that  can  be  utilized  by  the  entire  Navy 
acquisition  enterprise.  Product  lifecycle  management  is  an  integrated, 
information-driven  approach  to  all  aspects  of  a  product’s  life,  from  its  design 
through  manufacture,  deployment,  and  maintenance,  culminating  in  the  product’s 
removal  from  service  and  final  disposal.  Collaborative  PLM  software  suites  such 
as  Siemen's  Teamcenter,  PTC's  Windchill,  or  Dassault's  Enovia,  each  enable 
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accessing,  updating,  manipulating,  and  reasoning  about  product  information  that 
is  otherwise  being  produced  in  a  fragmented  and  distributed  environment. 

Collaborative  PLM  applications  will  allow  team  members  to  link  data 
from  various  sources,  to  all  other  program  structures  to  ensure  that  the 
relationships  and  interdependencies  are  understood.  This  understanding  will  lead 
to  participants  having  a  real  time  knowledge  or  a  program  status,  requirements, 
issues,  changes,  reviews,  operations,  and  so  on.  The  collaborative  PLM 
environment  can  effectively  manage  data,  more  effectively  manage 
configurations,  improve  collaboration  and  networking,  and  integrate  applications 
and  tools  across  the  entire  lifecycle.  These  benefits  are  just  a  few  of  the  ways 
collaborative  PLM  can  deliver  efficiencies  that  have  the  potential  to  dramatically 
reduce  TOC. 

Apply  the  LEAN  Product  Design  philosophy  to  the  design  process. 

Collaborative  PLM  was  created  to  manage  a  product  and  its  associated  data 
throughout  the  lifecycle,  from  cradle  to  grave.  LEAN  is  a  strategy  to  remove 
waste  throughout  processes,  saving  the  resources  expended  on  wasteful  activities. 
The  data  collected  and  organized  inside  the  collaborative  PLM  environment  will 
be  used  to  accomplish  the  LEAN  analysis  identifying  wasteful  processes.  Once 
the  more  efficient  process  is  identified,  collaborative  PLM  has  the  capability  to 
automate  the  workflow  and  institutionalize  the  efficient  processes,  making  both 
data  and  processes  accessible  to  users  throughout  the  lifecycle,  which  will 
eliminate  repetition,  redundancy,  errors,  and  other  forms  of  waste. 

Create  a  National  Design  Organization.  This  design  organization  would  be 

responsible  to  conduct  the  preliminary  design  of  every  new  ship-building 

program.  The  repetitions  through  the  design  process  would  create  a  very 

experienced  design  team  that  was  intimately  familiar  with  the  collaborative  PLM 

tools  and  how  to  translate  requirements  and  knowledge  into  a  good  ship  design. 

The  NDO  would  also  be  responsible  for  grooming  new  engineers,  provide  a  focal 

point  for  fleet  feedback  and  conduct  design  exercises  to  populate  the  collaborative 

PLM  idea  bank,  improve  standby  designs  and  integrate  new  technology  into 
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current  designs.  They  will  establish  and  maintain  design  and  engineering 
standards  used  during  naval  shipbuilding  programs,  and  manage  the  development 
of  mature  analytic  tools  required  during  design  and  certification. 

•  Establish  and  maintain  product  data  interoperability  standards.  PDI  will 
make  cross-program  collaboration  possible.  PDI  will  provide  a  consistent  fonnat 
for  data,  establishing  standards  required  for  the  development  of  applications  to  be 
integrated  into  the  collaborative  PLM  suite.  PDI  will  format  data  to  ensure  it  is 
useful  during  each  phase  of  the  lifecycle,  which  will  enable  collaboration  between 
phases  of  the  lifecycle,  thus  allowing  designers  to  focus  on  improving  the  product. 

•  Develop  and  integrate  design  and  certification  applications  inside  the 
collaborative  PLM  suite.  NAVSEA  can  improve  the  design  and  engineering 
tools  and  applications  available  to  assist  its  engineers  in  making  sound  decisions 
while  evaluating  the  multiple  options  of  a  particular  design.  These  new  tools 
could  be  developed  in  academia  or  in  the  public  or  private  sector  by  ensuring  that 
they  conform  to  the  data  interoperability  standards  maintained  by  the  NDO. 
Thus,  they  will  be  easily  integrated  into  the  collaborative  PLM  suite,  making 
utilization  across  the  acquisition  portfolio  easier. 

•  Institute  requirements  to  use  common  parts  catalog.  Once  a  part  or 
component  is  entered  into  the  collaborative  PLM  system,  any  designer  with 
access  can  use  it.  During  a  design,  the  common  catalog  can  be  accessed  and  the 
part  can  by  dragged  and  dropped  into  the  current  design,  saving  the  cost  and  time 
designing  and  testing  a  new  part.  Decreasing  the  number  of  unique  parts  across 
the  Navy  will  reduce  the  strain  on  the  logistics  pipeline,  will  decrease  the  number 
of  parts  sailors  must  learn  to  operate  and  maintainers  must  learn  to  fix. 

•  Retire  risk  as  early  in  the  process  as  possible,  to  decrease  the  volatility  of  our 
programs.  Every  part  in  the  collaborative  PLM  system  has  product  data  captured 
and  stored;  this  data  could  be  everything  related  to  its  design,  testing,  and  actual 
operational  performance.  As  more  knowledge  is  captured  inside  the  collaborative 


118 


PLM  system,  the  risk  of  an  unexpected  event  occurring  decreases.  As  the 
percentage  of  reused  components  in  a  design  is  increased,  the  risk  of  the  entire 
system  decreases. 

•  Employ  smart  products  to  automate  the  communication  of  information 
throughout  the  lifecycle  into  the  collaborative  PLM  suite.  Smart  products  are 
products  that  can  sense  and  communicate  information  about  their  condition  and 
environment.  For  instance  as  an  engine  communicates  its  performance  data,  trend 
lines  develop,  and  these  trend  lines  can  be  used  to  plan  maintenance  prior  to  any 
part  failing.  Scheduling  preventive  maintenance  based  on  actual  performance  will 
reduce  TOC.  Thus,  parts  will  only  be  replaced  when  failing,  instead  of  on  the 
date  recommended  by  the  vendor. 

•  Change  program  requirement  to  more  specifically  address  TOC. 

Establishing  operating  and  support  costs  and  readiness  is  a  key  parameter  during 
the  design.  Using  the  capability  of  collaborative  PLM  to  reduce  part  counts  will 
decrease  the  number  of  unique  parts  and  standardize  parts  across  the  acquisition 
portfolio. 

Ensure  the  collaborative  PLM  data  is  transferred  and  utilized  throughout 
the  lifecycle;  for  instance,  the  3D  model  can  be  used  during  the  initial  build  as 
well  as  during  future  ship  alterations. 

•  Use  the  evolutionary  versus  revolutionary  approach  concerning  technology 

insertion.  Evolutionary  product  development,  in  which  the  requirements  are  met 
over  several  generations  of  the  product,  offers  advantages  over  revolutionary 
technology  insertion.  This  method  decreases  the  risk  associated  with  maturing 
technology  concurrently  with  the  design  and  construction  of  a  new  ship. 

Once  the  warfighter  is  delivered  the  first  generation  platform, 
collaborative  PLM  can  help  designers  improve  the  second  generation  by 
facilitating  collaboration  between  the  operators  and  the  designers.  Feedback 
could  be  likes,  dislikes,  correcting  misinterpretations  of  the  requirements,  and 
changes  to  the  need  or  others.  The  smart  products  themselves  can  communicate 
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with  the  designer  leading  to  improvements  based  on  how  the  parts  are  performing, 
or  determining  if  they  were  over-  or  under  -engineered.  Additionally,  the  research 
labs  may  have  new  technology  that  is  now  mature  enough  for  integration  into  the 
second-generation  platform.  This  process  repeats,  and  each  successive  generation 
of  product  evolves  into  exactly  what  the  warfighter  needs,  while  never  accepting 
undue  risk  from  immature  technologies. 

•  Reduce  design  volatility  to  decrease  overall  program  risk.  Design  stability  is 
usually  achieved  when  the  3D  model  is  complete,  demonstrating  a  clear 
understanding  of  both  the  structure  as  well  as  every  system  and  how  those 
systems  integrate  into  the  building  blocks  of  the  ship.  Collaborative  PLM  can 
assist  the  design  team  with  integrating  the  applicable  data  and  ensure  that 
elements  are  not  overlooked  or  omitted,  efforts  necessary  to  achieve  design 
stability.  PLM  collaboration  tools  can  help  integrate  suppliers  into  the  process, 
which  is  very  important  to  design  stability,  as  they  not  only  provide  a  complete 
set  of  data  for  their  respective  systems,  but  also  are  the  experts  in  their  fields  and 
can  offer  valuable  insight  to  the  integration  into  the  total  ship. 

B.  CLOSING  REMARKS 

The  reforms  recommended  in  this  research  are  not  revolutionary;  in  fact,  if  you 
look  back  at  one  of  the  most  successful  programs  in  DoD  history  you  will  see  that  most 
of  the  principles  have  already  been  successfully  implemented.  With  the  AEGIS  program, 
the  Navy  for  the  first  time  embarked  on  a  total  “systems”  development.  Systems 
engineering  became  the  basis  for  the  entire  program,  from  initial  weapon  system 
development,  through  design  and  construction  of  the  ship,  to  development  of  the 
operation  and  the  support  infrastructure.  Rear  Admiral  Hood  who  served  as  the  Combat 
Systems  Engineer,  Technical  Director,  and  Program  Manager  during  the  AEGIS 
program,  recalled  that  the  systems  engineering  process  for  AEGIS  was  guided  by  the  firm 
hand  of  “the  father  of  AEGIS,”  RADM  Wayne  Meyer  (Hood,  2009,  p.  187).  Hood 
outlines  some  of  the  processes  and  beliefs  that  led  to  the  success  of  the  program,  such  as: 
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•  Early  and  constant  involvement  of  sailors,  as  well  as  frequently  sending 
industry  engineers  to  sea,  was  required.  This  process  “closed  the  information 
loop,”  engineers  understood  what  it  meant  to  go  to  sea  and  sailors  were  intimately 
involved  in  designing  the  warship  they  needed. 

•  No  one  was  allowed  to  work  in  isolation — teamwork  was  mandatory.  Naval 
engineers,  laboratory  scientists,  contractors,  and  sailors  were  brought  together  to 
collaborate.  Each  person’s  different  skill  set  created  a  synergy  that  inspired  true 
innovation. 

•  Field  Activities  were  enlisted  to  work  on  the  right  problem.  AEGIS  was 
cutting  edge  technology  and  the  smartest  people  were  employed  to  work  through 
problems.  Various  Navy  activities  were  recruited  to  solve  problems  in  their 
specialized  area.  Even  those  that  were  not  directly  assigned  to  the  AEGIS 
program  became  “AEGIS  people.” 

•  Contracts  were  structured  to  achieve  flexibility  and  facilitate 
communications.  The  contractor  and  government  worked  together  to  ensure  that 
immediate  corrective  actions  were  taken  when  necessary,  providing  near  real  time 
guidance  and  feedback.  Meyer  made  it  clear  the  principle  involved  was  “do 
what’s  right,  we’ll  sort  out  the  contracts  and  payments  later.” 

•  Only  what  could  be  proved  at  sea  was  taken  to  sea.  Technology  was  proven 
with  a  series  of  engineering  development  model  prior  to  being  included  in  the 
design.  This  helped  eliminate  setbacks  caused  by  immature  technology  (Hood, 
2009,  p.  187-190). 


The  Navy  has  the  opportunity  to  institutionalize  the  principles  RADM  Meyer  and 
the  AEGIS  program.  A  comprehensive  collaborative  PLM  suite,  accompanied  by  these 
reforms,  has  the  ability  to  fundamentally  change  how  we  design,  build,  and  maintain  the 
fleet,  making  the  defense  portfolio  solvent.  Both  of  the  major  defense  contractors, 
General  Dynamics  (DDG  1000,  SSN  774)  and  Northrop  Grumman  (LPD  17,  CVN  78, 
SSN  774),  already  employ  collaborative  PLM  applications  during  their  phase  of  the  ship 
design  process.  Like  them,  the  Navy  has  the  opportunity  to  build  on  their  efforts  to  create 
an  enterprise-wide  collaborative  PLM  solution  capable  of  supporting  the  entire 
shipbuilding  portfolio  throughout  the  entire  lifecycle.  Without  collaborative  PLM  and 
drastic  reforms  to  the  acquisition  community,  the  systems  and  platforms  the  Navy  needs 
to  meet  its  national  strategic  missions  might  never  be  delivered. 
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